JJAV Ai, tx, »v.’. iCHOOL 

MONTEREY. CALIFORNIA 93943-8008 



NAVAL POSTGRADUATE SCHOOL 

Monterey, California 




THESIS 



THE IMPLEMENTATION OF A 
ENTITY- RELATIONSHIP INTERFACE 
FOR A MULTI -LINGUAL DATABASE SYSTEM 

by 

Jacob A. Anthony III 
and 

Alfred J. Billings 
December 1985 



Thesis Advisor: David K. Hsiao 



Approved for public release; distribution is unlimited 

T2246?4 



TY CLASSIFICATION OF THIS PAGE 



REPORT DOCUMENTATION PAGE 



’ORT SECURITY CLASSIFICATION 



1b. RESTRICTIVE MARKINGS 



CURITY CLASSIFICATION AUTHORITY 



CLASSIFICATION /DOWNGRADING SCHEDULE 



3 DISTRIBUTION /AVAILABILITY OF REPORT 

Approved for public release; 
distribution is unlimited 



FORMING ORGANIZATION REPORT NUMBER(S) 



5. MONITORING ORGANIZATION REPORT NUMBER(S) 



kME OF PERFORMING ORGANIZATION 

al Postgraduate School 



6b. OFFICE SYMBOL 
(If applicable) 

52 



7a. NAME OF MONITORING ORGANIZATION 

Naval Postgraduate School 



DRESS {City, State, and ZIP Code) 

terey, CA 93943-5100 



7b. ADDRESS (Gty, State, and ZIP Code) 

Monterey, CA 93943-5100 



ME OF FUNDING /SPONSORING 
GANIZATION 



8b. OFFICE SYMBOL 
(If applicable) 



9. PROCUREMENT INSTRUMENT IDENTIFICATION NUMBER 



DRESS (City, State, and ZIP Code) 



10 SOURCE OF FUNDING NUMBERS 



PROGRAM 


PROJECT 


TASK 


WORK UNIT 


ELEMENT NO. 


NO. 


NO. 


ACCESSION NO 



LE (Include Security Classification) 

IMPLEMENTATION OF A ENTITY- RELATIONSHIP INTERFACE FOR THE MULTI - LINGUAL 
\BASE SYSTEM 



3SONAL AUTHOR(S) 

Db A. Anthony III 5 Alfred J. Billings 



13b TIME COVERED 


14 DATE OF REPORT (Year, Month, Day) 


15 PAGE COUNT 


FROM TO 


1985 December 


156 



/PE OF REPORT 

ter's Thesis 



PPLEMENTARY NOTATION 



COSATI CODES 


18. SUBJECT TERMS {Continue on reverse if necessary and identify by block number) 


ELD 


GROUP 


SUB-GROUP 


MLDS - Multi - Lingual Database System, MBDS. - 








Multi- Backend Database System, Entity-Relationship 








Data Model, Daplex, ABDL - Attribute-Based fContl 



STRACT {Continue on reverse if necessary and identify by block number) 

raditional ly , the design and implementation of a conventional database 
>7stem begins with the choice of a data model followed by the specifica- 
ion of a model-based data language. Thus, the database system is res- 
ricted to a single data model and a specific data language. An alter- 
ative to this traditional approach to database- system development is the 
ulti-lingual database system (MLDS) . This alternative approach enables 
he user to access and manage a large collection of databases via several 
ata models and their corresponding data languages without the afore- 
sntioned restriction. 

a this thesis we present the implementation of a entity- relationship/ 
aplex language interface for the MLDS. Specifically, we present the 
nplementation of an interface which translates Daplex language calls into 
ttribute -based data language (ABDL) requests. We describe the (cont) 



RPT. 


□ DTIC USERS 


21. ABSTRACT SECURITY CLASSIFICATION 

UNCLASSIFIED 




22b. TELEPHONE (Include Area Code) 

408-646-2253 


22c. OFFICE SYMBOL 

52Hq 



jTRIBUTlON/ AVAILABILITY OF ABSTRACT 
JNCLASSIFIED/UNLIMITED □ SAME 



AME OF RESPONSIBLE INDIVIDUAL 

af. D. K. Hsiao 



)RM 1473, 84 MAR 



All other editions are obsolete. 

1 



SECURITY CLASSIFICATION OF THIS PAGE 



SECURITY CLASSIPICATION OP THIS PAGE (Ph«n Dmtm Bnffd) 



18. SUBJECT TERMS (Continued) 

Data Language, Language Interface 

19. ABSTRACT (Continued) 

software engineering aspects of our implementation and an 
overview of the five modules which comprise our entity- 
relationship/Daplex language interface. 




5 ' N 0102- LF- 014- 6601 



2 



security classification of this PAGE(HTi«n Dmta Bnfrad ) 



Approved for Public Release, Distribution Unlimited. 



The Implementation of a 
Entity-Relationship Interface for the 
Multi-Lingual Database System 

by 

Jacob A. Anthony, III 
Lieutenant, United States Navy 
B.S., Pennsylvania State University, 1977 

and 



Alfred J. Billings 
Lieutenant, United States Navy 
B.S., University of Utah, 1977 



Submitted in partial fulfillment of the 
requirements for the degree of 

MASTER OF SCIENCE IN COMPUTER SCIENCE 

from the 

NAVAL POSTGRADUATE SCHOOL 
December 1985 



ABSTRACT 



•. I 

Traditionally, the design and implementation of a conventional database sys- 
tem begins with the choice of a data model followed by the specification of a 
model-based data language. Thus, the database system is restricted to a single 
data model and a specific data language. An alternative to this traditional 
approach to database-system development is the multi-lingual database system 
(MLDS). This alternative approach enables the user to access and manage a large 
collection of databases via several data models and their corresponding data 
languages without the aforementioned restriction. 

In this thesis we present the implementation of a entity-relationship/Daplex 
language interface for the MLDS. Specifically, we present the implementation of 
an interface which translates Daplex language calls into attribute-based data 
language (ABDL) requests. We describe the software engineering aspects of our 
implementation and an overview of the five modules which comprise our entity- 
relationship/Daplex language interface. 
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I. INTRODUCTION 



A. MOTIVATION 

During the past twenty years database systems have been designed and 
implemented using what we refer to as the traditional approach. The first step in 
the traditional approach involves choosing a data model. Candidate data models 
include the hierarchical data model, the relational data model, the network data 
model, the entity-relationship data model, or the attribute-based data model to 
name a few. The second step specifies a model-baised data language, e.g., DL/I 
for the hierarchical data model, or Daplex for the entity-relationship data model. 

A number of database systems have been developed using this methodology. 
For example, IBM has introduced the Information Management System (IMS) in 
the sixties, which supports the hierarchical data model and the hierarchical- 
model-based data language. Data Language I (DL/I). Sperry Univac has intro- 
duced the DMS-1100 in the early seventies, which supports the network data 
model and the network-model-based data language, CODASYL Data Manipula- 
tion Language (CODASYL-DML). More recently, there has been IBM’s intro- 
duction of the SQL/Data System which supports the relational model and the 
relational-model-based data language. Structured English Query Language (SQL). 
The result of this traditional approach to database system development is a 
homogeneous database system that restricts the user to a single data model and a 
specific model-based data language. 

An unconventional approach to database system development, referred to as 
the Multi-lingual Database System (MLDS) [Ref. l], alleviates the aforementioned 
restriction. This new system affords the user the ability to access and manage a 
large collection of databases via several data models and their corresponding data 
languages. The design goals of the MLDS involve developing a system that is 
accessible via four different interfaces, the hierarchical/DL/I, relational/SQL, 
network/DML, and entity- relationship/Daplex interfaces. 
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There are several advantages in developing such a system. Perhaps the most 
practical of these involves the reusability of database transactions developed on 
an existing database system. In MLDS, there is no need for the user to convert 
a transaction from one data language to another. MLDS permits the running of 
database transactions written in different data languages. Therefore, the user 
does not have to perform either manual or automated translation of existing tran- 
sactions in order to execute a transaction in MLDS. MLDS provides the same 
results even if the data language of the transaction originates at a different 
database system. 

A second advantage deals with the economy and effectiveness of hardware 
upgrade. Frequently, the hardware supporting the database system is upgraded 
because of technological advancements or system demand. With the traditional 
approach, this type of hardware upgrade has to be provided for all of the dif- 
ferent database systems in use, so that all of the users may experience system 
performance improvements. This is not the case in MLDS, where only the 
upgrade of a single system is necessary. In MLDS, the benefits of a hardware 
upgrade are uniformly distributed across all users, despite their use of different 
models and data languages. 

Thirdly, a multi-lingual database system allows users to explore the desirable 
features of the different data models and then use these features to better support 
their applications. This is possible because MLDS supports a variety of 
databases structured in any of the well-known data models. 

It is apparent that there exists ample motivation to develop a multi-lingual 
database system with many data model/data language interfaces. In this thesis, 
an entity-relationship/Daplex MLDS interface is developed. 

B. THE MULTI-LINGUAL DATABASE SYSTEM 

A detailed discussion of each of the components of MLDS is provided in sub- 
sequent chapters. In this section we provide an overview of the organization of 
MLDS. This assists the reader in understanding how the different components of 
MLDS are related. 

Figure 1 shows the system structure of a multi-lingual database system. The 
user interacts with the system through the language interface layer (LIL), using a 
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chosen user data model (UDM) to issue transactions written in a corresponding 
model-based user data language (UDL). LIL routes the user transactions to the 
kernel mapping system (KMS). KMS performs one of two possible tasks. First, 
KMS transforms a UDM-based database definition to a database definition of the 
kernel data model (KDM), when the user specifies that a new database is to be 
created. When the user specifies that UDL transaction is to be executed, KMS 
translates UDL transaction to a transaction in the kernel data language (KDL). 
In the first task, KMS forwards KDM data definition to the kernel controller 
(KC). KC, in turn, sends KDM database definition to the kernel database system 
(KDS). When KDS is finished with processing KDM database definition, it 
informs KC. KC then notifies the user, via LIL, that the database definition has 
been processed and that loading of the database records may begin. In the 




UDM 


: User Data Model 


UDL 


: User Data Language' 


LIL 


: Language Interface Layer 


KMS 


: Kernel Mapping System 


KC 


: Kernel Controller 


KFS 


: Kernel Formatting System 


KDM 


: Kernel Data Model 


KDL 


: Kernel Data Language 


KDS 


: Kernel Database System 


'igure 1. The Multi-Lingual Database System. 
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second task, KMS sends KDL transactions to KC. When KC receives KDL tran- 
sactions, it forw’ards them to KDS for execution. Upon completion, KDS sends 
the results in the KDM form back to KC. KC routes the results to the kernel 
formatting system (KFS). KFS reformats the results from the KDM form to the 
UDM form. KFS then displays the results in the correct UDM form via LIL. 

The four modules, LIL, KMS, KC, and KFS, are collectively known as the 
language interface. Four similar modules are required for each other language 
interface of the MLDS. For example, there are four sets of these modules where 
one set is for the hierarchical/DL/I language interface, one for the relational/SQL 
language interface, one for the network/DML language interface, and one for the 
entity-relationship/Daplex language interface. However, if the user writes the 
transaction in the native mode (i.e., in KDL), there is no need for an interface. 

In our implementation of the entity-relationship/Daplex language interface, 
we develop the code for the four modules. However, we do not integrate these 
modules with the KDS as shown in Figure 1. The Laboratory of Database Sys- 
tems Research at the Naval Postgraduate School has procurred the new computer 
equipment for the KDS. When the equipment is installed, the KDS is to be 
ported over to the new equipment. The MLDS software is then to be integrated 
with the KDS. Although not a very difficult undertaking, it is neverless outside 
the focus of this thesis. 

C. THE KERNEL DATA MODEL AND LANGUAGE 

The choice of a kernel data model and a kernel data language is the key deci- 
sion in the development of a multi-lingual database system. The overriding ques- 
tion, when making such a choice, is whether the kernel data model and kernel 
data language is capable of supporting the required data-model transformations 
and data-language translations for the language interfaces. 

The attribute-based data model proposed by Hsiao [Ref. 2], extended by 
Wong [Ref. 3], and studied by Rothnie [Ref. 4], along with the attribute-based 
data language (ABDL), defined by Banerjee [Ref. 5], have been shown to be 
acceptable candidates for the kernel data model and kernel data 
language, respectively. 
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Why is the determination of a kernel data model and kernel data language so 
important for MLDS? No matter how multi-lingual MLDS may be, if the under- 
lying database system (i.e., KDS) is slow and inefficient, then the interfaces may 
be rendered useless and untimely. Hence, it is important that the kernel data 
model and kernel language be supported by a high-performance and great- 
capacity database system. Currently, only the attribute-based data model and 
the attribute-based data language are supported by such a system. This system 
is the multi-backend database system (MBDS) [Ref. l]. 

D. THE MULTI-BACKEND DATABASE SYSTEM 

The multi-backend database system (MBDS) has been designed to overcome 
the performance problems and upgrade issues related to the traditional approach 
of database system design. This goal is realized through the utilization of 
multiple-backends connected in a parallel fashion. These backends have identical 
hardware, replicated software, and their own disk systems. In a multiple-backend 
configuration, there is a backend controller, which is responsible for supervising 
the execution of database transactions and for interfacing with the hosts and 
users. The backends perform the database operations with the database stored 
on the disk system of the backends. The controller and backends are connected 
by a communication bus. Users access the system through either the hosts or the 
controller directly (see Figure 2). 

Performance gains are realized by increasing the number of backends. If the 
size of the database and the size of the responses to the transactions remain con- 
stant, then MBDS produces a reciprocal decrease in the response times for the 
user transactions when the number of backends is increased. On the other hand, 
if the number of backends is increased proportionally with the increase in data- 
bases and responses, then MBDS produces invariant response times for the same 
transactions. A more detailed discussion of MBDS is found in [Ref. 6|. 

E. THESIS OVERVIEW 

The organization of our thesis is as follows: In Chapter II, we discuss the 
software engineering aspects of our implementation. This includes a discussion of 
our design approach, as well as a review of the global data structures used for the 
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Bus 



Figure 2. The Multi-Backend Database System, 
implementation. Chapter III discusses the storage and creation of the Daplex 
schemas. In Chapter IV, we outline the functionality of the language interface 
layer. In Chapter V, we articulate the processes constituting the kernel mapping 
system. In Chapter VI, we conclude the thesis. 

Appendix A contains the data structure used for the interface, and Appendix 
B provides the modules for the storage and retrieval of the Daplex schemas. The 
detailed specifications of the interface modules (i.e., LIL and KMS) are given in 
Appendices C and D respectively. The specifications of the source data language, 
Daplex, and the target data language, ABDL, are found in [Ref. 7] and [Ref. 8], 
respectively. Throughout this thesis, we provide examples of Daplex requests 
and their translated ABDL equivalents. All examples involving database 
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operations presented in this thesis are based on the university database described 
in the Daplex User’s Manual [Ref. 7], and shown in Figure 3. 



DATABASE university IS 

TYPE person; 

SUBTYPE employee; 

SUBTYPE support_staff; 

SUBTYPE faculty; 

SUBTYPE student; 

SUBTYPE graduate; 

SUBTYPE undergraduate; 

TYPE course; 

TYPE department; 

TYPE enrollment; 

TYPE rank jame IS (assistant, associate, full); 
TYPE semester^ame IS (fall, spring, summer); 
TYPE grade joint IS FLOAT RANGE 0.0 .. 4.0; 

TYPE person IS 
ENTITY 

name : STRING (l .. 25); 

ssn : STRING (l .. 9) := ”000000000"; 

END ENTITY; 

SUBTYPE employee IS person 
ENTITY 

home _address : STRING (1 .. 50); 
office : STRING (1 .. 8); 
phones : SET OF STRING (1 .. 7); 
salary : FLOAT; 

dependents : INTEGER RANGE 0 .. 10 ; 
END ENTITY; 

SUBTYPE support_staff IS employee 
ENTITY 

supervisor : employee WITHNULL; 
full_time : BOOLEAN; 

END ENTITY; 

SUBTYPE faculty IS employee 
ENTITY 

rank : rank jame; 

teaching : SET OF course; 
tenure : BOOLEAN := FALSE; 

dept : department; 

END ENTITY; 
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SUBTYPE student IS person 
ENTITY 

advisor : faculty WITHNULL; 

major : department; 

enrollments : SET OF enrollment; 

END ENTITY; 

SUBTYPE graduate IS student 
ENTITY 

advisory^committee : SET OF faculty; 

END ENTITY; 

SUBTYPE undergraduate IS student 
ENTITY 

gpa : grade_point := 0.0; 

year : INTEGER JIANGE 1 .. 4 := 1; 

END ENTITY; 

TYPE course IS 
ENTITY 

title : STRING (1 .. 10); 

dept : department; 

semester : semester_name; 

credits : INTEGER; 

END ENTITY; 

TYPE department IS 
ENTITY 

name : STRING (1 .. 20); 

head : faculty WITHNULL; 

END ENTITY; 

TYPE enrollment IS 
ENTITY 

class : course; 

grade : grade_point: 

END ENTITY; 

UNIQUE ssn WITHIN person; 

UNIQUE name WITHIN department; 

UNIQUE title, semester WITHIN course; 
OVERLAP graduate WITH faculty; 

END university; 



Figure 3. The University Database. 
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II. SOFTWARE ENGINEERING OF A LANGUAGE INTERFACE 



In this chapter, we discuss the various software engineering aspects of 
developing a language interface. First, we describe our design goals, and then 
outline the design approach that we have taken to implement the interface. 
Included in this section are discussions of our implementation strategy, our 
software development techniques, and the salient characteristics of the language 
interface software. Next, a critique of our implementation is provided, and then 
we describe the data structures used in the interface. Finally, we provide an 
organizational description of the next four chapters. 

A. DESIGN GOALS 

We are motivated to implement a Daplex interface for MLDS using MBDS 
as the kernel database system, the attribute-based data model as the kernel data 
model, and the attribute-based data language, ABDL, as the kernal data 
language. It is important to note that we do not propose changes to the kernel 
database system or language. Instead, our implementation resides entirely in the 
host computer. All user transactions in Daplex are processed in the Daplex inter- 
face. MBDS continues to receive and process requests in the syntax and seman- 
tics of ABDL. 

In addition, our interface will be transparent to the user. For example, an 
employee in a corporate environment with previous Daplex experience could log 
into our system, issue a Daplex request and receive resultant data in an entity- 
relationship format. The employee requires no training in ABDL or MBDS 
procedures prior to utilizing the system. 

B. AN APPROACH TO THE DESIGN 

1. The Implementation Strategy 

There are a number of different strategies we might have employed in the 
implementation of the Daplex language interface. For example, there is the 
build-it-twice full-prototype approach, the level- by- level top-down approach, the 
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incremental development approach, and the advancemanship approach 
[Ref. 9: pp. 41-46]. We have predicated our choice on minimizing the 
"software-crisis" as described by Boehm [Ref. 9; pp. 14-31). 

The strategy we have decided upon is the level-by-level top-down 
approach. Our choice is based on first, a time constraint. The interface has to 
be developed in approximately two quarters. Second, the level-by-level top-down 
approach lends itself to the natural evolution of the interface. The system is ini- 
tially thought of as a "black box" (see Figure 1 again) that accepts Daplex tran- 
sactions and then returns the appropriate results. The "black box" is then 
decomposed into its four modules, LIL, KMS, KC, and KFS. These modules, in 
turn, are further decomposed into the necessary functions and procedures to 
accomplish the appropriate tasks. 

2. Techniques for Software Development 

In order to achieve our design goals, it is important to employ effective 
software engineering techniques during all phases of the software development 
life-cycle. These phases, as defined by Ledthrum [Ref. 10: p. 27], are as follows: 

(1) Requirements Specification - This phase involves 
stating the purpose of the software: "what" is to 
be done, not "how" it is to be done. 

(2) Design - During this phase an algorithm is devised 
to carry out the specification produced in the 
previous phase. Tnat is, "how'^ to implement the 
system is specified during this phase. 

(3) Coding - In this phase, the design is translated 
into a programming language. 

(4) Validation - During this phase, it is ensured that 
the developed system functions as originally 
intended. That is, it is verified that the system 
actually does what it is supposed to do. 

The first phase of the life-cycle has already been performed. The 
research done by Demurjian and Hsiao [Ref. l] has described the motivation, 
goals, and structure of MLDS. The research conducted by Goisman [Ref. 11] 
has extended this work to describe in detail the purpose and design of the Daplex 
interface. Accordingly, the requirements specifications are derived from the 
above research. 
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The system implementation methodology was essentially accomplished 
and proven during the implementation of DL/I and SQL into MLDS 
[Refs. 12 and 13]. Our task was to adapt the DL/I and SQL approaches as 
necessary for the Daplex implementation. 

We have used the C programming language [Ref. 14] to translate the 
design into executable code. Initially, we were not conversant in the language. 
However, the simple syntax of C and our background in structured languages has 
made C relatively easy for us to learn. 

The main advantage of C is the programming environment in which it 
resides, the UNIX operating system. This environment has permitted us to parti- 
tion the Daplex interface, and then manage these parts in an effective and effi- 
cient manner. The primary disadvantage to the use of C is that the poor error 
diagnostics presented by the C compiler can and at times did make debugging 
difficult. There is an on-line debugger available in UNIX for use with C, but we 
chose to use conditional computation and diagnostic print statements to aid in 
the debugging process. To validate our system we have used path testing [Ref 
15], a traditional testing technique. We have checked boundary cases, and we 
have tested those cases considered "normal”. It is noteworthy to mention that 
testing does not prove the system correct, but may only indicate the absence of 
problems with the cases that have been tested. 

3. Characteristics of the Interface Software 

We realize that in order for the Daplex interface to be successful, that it 
must be well designed and well structured. Further, we are cognizant of certain 
characteristics that the interface must possess. Specifically, it must be simple, 
and easily read and understood. 

The ease with which the code can be understood is vital to keeping the 
program maintenance effort low. As reported by Fairley [Ref. 16: p. 82], roughly 
60% of all software life-cycle costs are incurred after the software becomes opera- 
tional, so it is important that a maintenance programmer can easily grasp the 
functionality of the Daplex interface and the relationship between it and the 
other portions of the system. 
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We have made every effort to ensure that the C code we have written 
has these characteristics. For instance, we have avoided the use of the shorthand 
notations available in C and have used the more readable, and therefor longer 
version of C whenever possible. This extra code has often made the difference 
between comprehensible code and cryptic notations. Further, the interface 
software does not have any hidden side-effects that could pose problems months 
or years from now. As a matter of fact, we have intentionally minimized the 
interaction between procedures to ease the burden of maintainability. 

In addition to the above software engineering techniques, we require pro- 
grammers to update documentation of the interface code when changes are made. 
Hence, maintenance programmers have current documentation at all times, and 
the problem of trying to identify the functionality of a program with dated docu- 
mentation -is alleviated. To take the software engineering a step further, the data 
structures are designed to be as general as possible. Thus, it is an eeisy task to 
modify or rectify these structures to meet the demands of an evolving system. 

A final characteristic of a sound Daplex interface is extensibility. A 
software product has to be designed in a manner that permits the easy modifica- 
tion and addition of code. In this light, we have placed "stubs” in appropriate 
locations within KFS to permit easy insertion of the code needed to handle multi- 
ple horizontal screens of output. 

C. THE DATA STRUCTURES 

The Daplex language interface has been developed as a single-user system. It 
is recognized however, that at some point in time the Daplex interface will be 
updated to a multi-user system. Accordingly, two different concepts of data are 
used in the interface: (l) data structures shared by all users, and (2) structures 
specific to each user. In accordance with the first data structure concept, the 
Daplex implementation has, whenever possible, used and added to the existing 
generic data structures generated by the previous implementations of DL/I and 
SQL. However, due to the complexity of the entity-relationship model, an addi- 
tional large set of unique and specific data structures was required for the Daplex 
implementation. 
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1. Data Shared by All Users 

The following discussion of data structures makes extensive use of the 
university database described in Figure 3. A frequent reference to Figure 3 may 
aid the reader greatly in understanding the following material. 

The data structures that are shared by all users are the database schemas 
defined by the users thus far. In our case, these are entity-relationship schemas, 
consisting of entities and the relationships (functions) between the entities. 
These are not only shared by all users, but also shared by the four modules of the 
MLDS, i.e., LIL, KMS, KC, and KFS. It is important to note that this structure 
is represented as a union and is generic in the sense that it can be used to sup- 
port the SQL, CODASYL, DL/I, and Daplex needs. Figure 4 depicts this data 
structure. 

union dbid_node 

{ 

struct rel_dbid^ode *rel; 
struct hie_dbid_node *hie; 
struct net_dbid_node *net; 
struct ent_dbid^ode *ent; 

} 

Figure 4. The dbid_node Data Structure. 

The main concern of this thesis, however, is with the entity-relationship 
model. In this regard, the fourth field of this structure points to a node that con- 
tains the information about an entity-relationship database. Figure 5 illustrates 
this record. 

The first field is simply a character array containing the name of the 
entity-relationship database. The second field contains a pointer to the base-type 
nonentity node, and the following field simply contains an integer value that 
represents the number of these nodes in the database. The fourth field points to 
the entity node, and as before the field that immediately follows contains an 
integer value representing the number of such nodes. The sixth field contains a 
pointer to the generalized entity supertype node and the seventh field the integer 
value of the number of these supertypes. The eighth and tenth fields contain 



20 



struct ent_dbid_node 
{ 



char 


edn name[DBNLength -1- l|; 


struct 


ent non node *edn nonentity; 


int 


edn num nonent; 


struct 


ent node *edn entity; 


int 


edn num ent; 


struct 


gen sub node *edn subptr; 


int 


edn num gen; 


struct 


sub non node *edn nonsubptr 


int 


edn num nonsub; 


struct 


der^on_node *edn nonderptr; 


int 


edn_jium der; 


struct 


ent dbid node *edn next db; 



}; 



Figure 5. The ent_dbid_node Data Structure, 
pointers to the nonentity subtypes and nonentity derived types respectively, and 
the ninth and eleventh fields contain the integer value for the number of such 
nodes. Finally, the twelfth field points to the next entity-relationship database 
node. 

Figure 6 depicts the entity node structure. The first field of this struc- 
ture is a character array which holds the name of the entity, and the second field 
is an integer representation of the number of functions associated with the entity 
that this node represents. For instance, the "person" entity has two functions 
associated with it, "name" and "ssn". The third field is an integer representation 



struct ent_node 

{ 

char en_name[ENLength -t- l]; 
int en_num_funct; 

int en_terminal; 

struct function _node *en_ftnptr; 
struct ent _node *en_next_ent; 

}; 



Figure 6. The ent_node Data Structure. 
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of a boolean function and indicates whether or not the entity is a terminal type, 
i.e., not a supertype. 

The structure of the gen_sub_node is shown in Figure 7. The first field, 
similar to previous nodes, holds the name of the generalized entity subtypes. An 
example applied to the university data base is ”support_staff”. The second field 
holds the number of functions associated with each entity subtype, and the third 
field is an integer representation of a boolean function and holds a *'l" if the 
generalized entity is a subtype and not a supertype. 

struct gen_sub_node 

{ 

char gsn_name[ENLength + 1]; 
int gsn^um_funct; 

int gsn_terminal; 

struct overlap_ent_node *gsn_entptr; 
int gsn^um_ent; 

struct function^ode *gsn_ftnptr; 
struct overlap_sub^ode *gsn_subptr; 
int gsn^um_sub; 

struct gen_sub^ode *gsn^ext_genptr; 

}; 

Figure 7. The gen_sub^ode Data Structure. 

The fourth field holds a pointer to the entity supertype. In the case of 
"employee" the supertype is "person". The fifth field indicates the number of 
those entities. The sixth field holds a pointer to a function associated with the 
generalized subtype, for instance, "salary". The seventh field holds a pointer to 
the subtype supertype. For example, the supertype for the subtype 
"support_staff" is "employee". The eighth field maintains a record of the 
number of such subtype supertypes. The final field simply points to the next 
gen_sub^ode. 

The ent^on^ode record is shown in Figure 8, and contains information 
about each nonentity base-type in the database. The first field of the record 
holds the name of the nonentity node, for example, "rank^ame". The second 
field holds the character that indicates the type of nonentity node, either "i". 
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integer; "e", enumeration; ’’f, floating point; "s", string; "b", boolean. The next 
field contains an integer that indicates the maximum length of the base-type 
value. 

The fourth field contains an integer representation of. a boolean value, a 
"1" or "0”, that indicates whether or not there is a range associated with the 
nonentity node. For example, the nonentity "grade_point” has a range of 0.0 to 
4.0, while "rank-name” is without a range. The fifth field contains an integer that 
represents the number of different values that the nonentity can assume. As an 
example, both "rank _name" and "semester^ame" can assume three values, but 
"grade joint" can assume 40 different values. 

struct ent non node 



{ 

char 


enn name[ENLength -|- 1]; 


char 


enn type; 


int 


enn total length; 


int 


enn range; 


int 


enn num values; 


struct 


ent value *enn value; 


int 


enn constant; 


struct 


ent non node *enn next 



}; 

Figure 8. The ent jon_node Data Structure 
The sixth field contains a pointer to the actual value of the base-type, 
and the seventh field contains an integer representation of a boolean value that 
indicates if the actual value of the base-type is a constant. There are no con- 
stants in the university database, but, as an example, the value of the base-type 
could assume the constant value of pi (3.14159265) or Avogadro’s number (6.023 
X 10 '23). The eighth and final field contains a pointer to the next nonentity 
node. 

The subjonjode is shown in Figure 9. This structure is almost identi- 
cal in form and similar in purpose to the ent jonjode of Figure 6. The main 
difference in purpose between the two structures is that the ent_non _node is for a 
base-type nonentity and the subjonjode is for a subtype nonentity. The 
difference in form between the two structures is the absence of constants in the 
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struct sub^on^ode 
{ 



char 


snn name[ENLength + l]; 


char 


snn type; 


int 


snn total length; 


int 


snn range; 


int 


snn num values; 


struct 


ent value *snn value; 


struct 


sub non node *snn next 



}; 



Figure 9. The sub non node Data Structure. 
sub_non^ode. Maintaining two separate constant lists would be redundant, 
hence the constants are found only in the ent^on_node. 

The next node, similar to both the ent^on_node and the sub_non^ode, 
is the der^on _node, shown in Figure 10. The der_non^ode is identical in struc- 
ture to the sub_non^ode and differs in function in that it applies to the derived 
nonentity subtypes. 



struct der non node 



{ 

char 


dnn name[ENLength -1- l]; 


char 


dnn type; 


int 


dnn total length; 


int 


dnn range; 


int 


dnn num values; 


struct 


ent value *dnn value; 


struct 


der non node *dnn next 



}; 



Figure 10. The der_non_node Data Structure. 

The final node that we will discuss is this section is the function^ode, 
shown in Figure 11. The function^ode defines the structures for each function 
type declaration. As an example, the function "dept" returns the entity 
"department" when applied to the entity "faculty". 

The first field of the function^ode points to the name of the function, in 
this example the name is "dept". The second field holds the type, an "e" in this 
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struct function node 



char 


fn name[ENLength-|-l|; 


char 


fn_type; 


int 


fn range; 


int 


fn total length; 


int 


fn num value; 


struct 


ent value *fn value; 


struct 


ent node *fn entptr; 


struct 


gen sub node *fn subptr; 


struct 


ent non node *fn nonentptr; 


struct 


sub non node *fn nonsubptr; 


struct 


der non node *fn nonderptr; 


int 


fn entnull; 


int 


fn unique; 


struct 


function node *fn next fntptr; 



Figure 11. The function_node Data Structure, 
case. The third field indicates when the function has a range of values, the fourth 
field indicates the length and the fifth field indicates the number of values, if any. 
In this example, all three fields would hold a "0". 

The sixth field would hold the actual value, if there were any, and the 
next five fields hold pointers to the type to which a particular function belongs. 
A function may belong to more than one type, but it is extremely unlikely that it 
would belong to all five. In our example, the function "dept” belongs to only one 
type, the entity "department", hence only the ent^ode pointer, fn_entptr, will 
contain any information, the remaining four type field pointers will be empty. 

The twelfth field indicates if there is an associated entity value. It is ini- 
tialized to hold a "0" and in the above example maintains that "0". The thir- 
teenth field indicates whether or not the function is unique. It too is initialized 
to "0", and in our example maintains that "0". The final field simply contains a 
pointer to the next function. 

2. Data Specific to Each User 

This category of data represents information required to support each 
user’s particular interface needs. The data structures used to accomplish this 
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may be thought of as forming a hierarchy. At the root of this hierarchy is the 
user^nfo record, shown in Figure 12, which maintains information on all current 
users of a particular language interface. The user^nfo record holds the ID of the 
user, a union that describes a particular interface, and a pointer to the next user. 
The union field is of particular interest to us. As noted earlier, a union serves as 
a generic data structure. 

struct user info 

{ 

char uid[UIDLength + l]; 

union li_info li_type; 

struct user_info *next_user; 

} 

Figure 12. The user^nfo Data Structure. 

In this case, the union may hold the data for a user accessing either an 
SQL language interface layer, a DL/I LIL, a CODASYL-DML LIL, or a Daplex 
LIL. The li_info union is shown in Figure 13. 

We are only interested in the data structures containing user information 
that pertain to Daplex, or entity-relationship, language interface. This structure 
is referred to as dap^nfo and is depicted in Figure 14. The first field of this 
structure, dpi_curr_db, is itself a record and contains currency information on the 
database being accessed by a user. The second field, dpi^ile, is also a record. 
The file record contains the file descriptor and file identifier of a file of Daplex 
transactions, either requests or database descriptions. The next field, 
dpi_dml_tran, is also a record, and holds information that describes the Daplex 

union li_info 

{ 

struct sqMnfo li_sql; 
struct dlwnfo li_dli; 
struct dml_info li_dml; 
struct dap_mfo lijdap; 

} 

Figure 13. The li_info Data Structure. 
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struct dap_mfo 



{ 



struct 


curr db info 


dpi curr db; 


struct 


file info dpi file; 


struct 


tran info 


dpi dml tran; 


int 


dap operation; 




struct 


ddlj^nfo ^ 


‘dpi ddl files; 


union 


kms info 


dpi kms data 


union 


kfs info 


dpi kfs data; 


union 


kc info 


dpi kc data; 


int 


dap error; 




int 


dap answer; 




int 


dap buff count 


5 



}; 



Figure 14. The dap_info Data Structure, 
transactions to be processed. This includes the number of requests to be pro- 
cessed, the first request to be processed, and the current request being processed. 
The fourth field of the dap_info record, dap_operation, is a flag that indicates the 
operation to be performed. This may be either the loading of a new database, or 
the execution of a request against an existing database. The next field, 
dpi_ddl_files, is a pointer to a record describing the descriptor and template files. 
These files contain information about the ABDL schema corresponding to the 
current entity-relationship database being processed, i.e., the ABDL schema 
information for a newly defined entity-relationship database. The following 
fields, dpi_kms_data, dpi_kfs_data and dpi _kc _data, are unions that contain 
information required by the KMS, KFS and KC, respectively. These are 
described in more detail in later chapters. The next field, error, is an integer 
value representing a specific error type. The next field, answer, is used by the 
LIL to record answers received through its interaction with the user of the inter- 
face. The last field, buff_count, is a counter variable used in the KC to keep 
track of the result buffers. 
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D. THE ORGANIZATION OF THE NEXT FOUR CHAPTERS 

The following four chapters are meant to provide the user with a more 
detailed analysis of the modules constituting MLDS and Daplex implementations. 
Each chapter begins with an overview of what each particular module does and 
how it relates to the other modules. The actual processes performed by each 
module are then discussed. This includes a description of the actual data struc- 
tures used by the modules. Each chapter concludes with a discussion of module 
shortcomings. 
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III. STORAGE AND RETRIEVAL OF THE DAPLEX SCHEMAS 



The first modules that we discuss concern the storage of the Daplex schemas 
from memory and the recreation of those schemas in memory from a file. It is 
understood that these modules are not as conceptually interesting as the LIL, 
KMS, KC or KFS, but they are important, and are included here for 
completeness. 

The reader is reminded that Appendix B contains the modules for storage 
and retrieval and should be consulted frequently to ensure a thorough under- 
standing of this chapter. 

A. DAPLEX SCHEMA STORAGE 

Early in the design phase of the storage module, we realized that several 
items in the schema could be stored more than once and storage space unneces- 
sarily wasted. Accordingly, we made a concerted effort to avoid storing redun- 
dant data and mapped the data to the correct structure with the use of pointers. 

The Daplex schemas are tied together as they are written to a file by a series 
of pointer manipulations. The pointer that is responsible for each ent_dbid_node, 
hence for the entire Daplex database, is known as db_ptr. Generally, the db_ptr 
is set to the head of the database and then passed to the routine responsible for 
writing the contents of that specific portion of the ent_dbid _node to a file. 
Accordingly, the entire ent_dbid_node is not written to the file at this time, 
rather, only the database name, edn_name, and the number of nonentities, 
edn _num _nonent, are stored, (see Figure 5 again) In general, as the pointer is 
sequenced through the node, each structure it encounters is processed in turn, 
storing necessary information while at the same time avoiding information that 
may be previously stored in another node. 

The first structure that the pointer encounters is the ent_non _node (as in 
Figure 5). The routine for storing the nonentity nodes is known as 
proc_ent _non _node. The entire nonentity node is stored at this time, (see Figure 
8 again) including any associated entity values, as this information is not 
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duplicated elsewhere. The pointer in the calling routine then moves to the next 
nonentity node and the entire procedure is repeated. This process continues until 
all the nonentity nodes have been stored. 

The db_ptr, is then set to the entity nodes (as in Figure 5), the procedure 
for processing the entity nodes, wr_ent^ode, is executed, and the entire set of 
entity nodes is processed, (see Figure 6 again) However, the functions associated 
with the respective entities are not processed, as all the functions are handled 
separately. 

The routine wr gen sub node, processes the next node, the generalized entity 
subtypes. Only the first three fields, gsn_name, gsn_num_funct, and 
gsn_terminal, (see Figure 7 again) are stored directly by this routine, the remain- 
ing fields are stored immediately after execution of wr_gen_sub^ode, and within 
the main routine. 

The remainder of the gen_sub^ode is processed in the main routine. This 
segment of code is handled in the main routine instead of in a separate procedure 
because the pointer manipulations are more easily handled here and because this 
data is processed only once, a separate routine was not considered necessary. 
The reader should note that the subtypes with entity supertypes, i.e., the 
overlap_ent_nodes, and the terminal subtypes that define one or more subtypes, 
i.e., the overlap_sub^odes, that are associated with the gen_sub^ode are all 
processed at this time. 

The subtype nonentity nodes are processed within the proc_sub_non_node 
routine. First, the db_ptr is set to point at the edn^onsubptr (as in Figure 5). 
The proc sub non node is then called, and the entire sub non node is stored. 

The derived type nonentity nodes are processed in exactly the same manner 
as the sub^on_node. The db_ptr is set to point at edn_nonderptr (as in Figure 
5) and the entire der^on_node is processed, (see Figure 10 again) 

The functions associated with the entity nodes are the next items stored. The 
reader may remember that we chose not to store these functions earlier. We 
store the functions now by first setting the db_ptr to point at the entity nodes 
and then call wr _all_ent^ode, a routine that calls a second routine, 
proc function node, that processes all of the functions. 
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The proc function node routine tracks sequentially through the appropriate 
function node (see Figure 11 again) and stores data for every field. Since the 
ent_node, gen_sub^ode, ent_non^ode, sub^on_node and der^on node (as in 
Figure 5) may or may not have data aasociated with them, we have chosen to 
place a " in the empty fields to maintain the integrity of the database. 

The functions associated with the gen_sub^odes (as in Figure 7) are stored 
in a manner very similar to the process just described. The db^tr is set to point 
at the gen_sub^ode and once again the proc_function^ode routine is called. 

At this point the database for one ent_dbid_node has been stored. The pro- 
gram checks to see if any more ent_dbid_nodes remain to be stored. If so, the 
above procedures are repeated. If not, a is inserted at the end of the data- 
base as an end of database marker. 

B. RETRIEVAL OF THE DAPLEX SCHEMA 

The process for retrieving the Daplex schemas from secondary storage and 
loading them into memory is almost a reverse of the storage procedure. Different 
structures are used, as the save module was written by one member of the team 
and the retrieval module by the other; otherwise, the process is basically a 
reversal. 

The routine that reads data into the first Daplex database, i.e., the first 
ent_dbid^ode, is rd_ent_dbid_node. The memory is first allocated, the pointers 
nulled, and then the first two fields, edn^ame and edn^um^onent, (as in Fig- 
ure 5) are loaded into memory. The remaining fields are loaded in order along 
with the respective field data. 

The pointer sequences to the next allocated space in memory and the routine 
that reads in the data for the nonentity nodes, rd_ent_non_node, is executed (as 
in Figure 8). As before, the entire nonentity node is processed at one time. 

The next structures to be filled, at least partially, are the entity nodes (as in 
Figure 6). As with wr_ent_node, the functions associated with rd_ent^ode, and 
therefore the entities, are processed later. 

The generalized entity subtypes are the next nodes to be processed. As with 
the storage routine, only three of the fields gsn_name, gsn^um^unct and 
gsn_terminal, are processed in rd_gen_sub^ode (as in Figure 7). However, 
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unlike the storage routine, the remainder of the gen_sub_node is handled in two 
smaller routines, rd_overlap_ent^ode and rd_overlap^ub^ode. 

After the first three fields of the generalized subtypes are processed, the 
pointer is sequenced and the routine that handles the subtypes with one more 
entity supertypes, rd_overlap_ent^ode, is executed. The rd_overlap_ent_node 
routine checks for the presence of subtypes with one or more supertypes and then 
loads those names into memory. The routine rd_overlap_sub_node functions 
exactly as rd_overlap_ent_node, but on the subtype supertypes. 

After the overlap nodes are processed, the pointer sequences and the subtype 
nonentity nodes are allocated and filled. This process occurs within the 
rd sub non node routine (as in Figure 9). 

The derived type nonentity nodes (as in Figure 10) are processed in exactly 
the same manner as the sub_non_node. The pointer is sequenced, the memory 
allocated, and data entered in exactly the same fashion. The functions associated 
with the entity nodes axe the next items loaded into memory. The functions are 
loaded by first sequencing the pointer and then calling the routine responsible for 
loading the functions, rd_function_node. The rd_function^ode routine, along 
with the previous routines, first allocates the necessary memory and then nulls 
the appropriate pointers. The routine then tracks through the function node (as 
in Figure 11) and loads those fields with data. Since it is possible for any of the 
ent_nodes, gen_sub^odes, ent_non_nodes, sub_non_nodes or der_non_nodes to 
be without data, the routine first checks those nodes to see if they contain a " ' 
the symbol for an empty node. Finally, the module checks to see if it has encoun- 
tered a the symbol for end of database. If so, all processes are terminated. 

We have written a small main routine that first executes the retrieval of an 
existing database and then executes the saving of that database to a file. The 
main routine calls the two modules previously discussed and then executes a 
print statement for every retrieval and save action. This methodology has allowed 
the authors to more effectively debug the programs. 
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IV. THE LANGUAGE INTERFACE LAYER (LIL) 

The second set of modules that we will discuss concern LIL, the first modules 
in the Daplex mapping process. LIL is used to control the order in which the 
other modules are called, and allows the user to input transactions from either a 
file or the terminal. A transaction may take the form of either a database 
description (DBD) of a new database, or a Daplex request against an existing 
database. A single transaction may contain multiple requests, allowing a group 
of requests to perform a single task. For example, several "atomic" statements, 
those statements that are executed as an indivisible action with respect to the 
database, could be executed together as a single transaction. 

The mapping process occurs when LIL sends a single transaction to KMS. 
After the transaction has been received by KMS, KC is called to process the 
transaction. Control always returns to LIL, where the user may either continue 
with another transaction or close the session by exiting to the operating system. 

LIL is menu-driven, and when the transactions are read from either a file or 
the terminal, they are stored in the dap_req_info data structure. If the transac- 
tions are database descriptions, they are sent to the KMS in sequential order. If 
the transactions are Daplex requests, the user is prompted by another menu to 
selectively choose an individual request to be processed. The menus provide an 
easy and efficient way for the user to view and select the methods of request pro- 
cessing desired. Each menu is tied to its predecessor, so that by exiting one 
menu the user is moved up the "menu tree". This allows the user to perform 
multiple tasks in one session. 

A. THE LIL DATA STRUCTURES 

LIL uses three data structures to store the user’s transactions and control the 
transaction sent to KMS. It is important to note that these data structures are 
shared by both LIL and KMS. 

The first data structure is named tran info and is shown in Figure 15. The 
first field of this record, ti first req, is the pointer to the first request data 
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struct tran_info 

{ 

union req_[nfo ti_first^eq; 

union req_j^nfo ti_curr_req; 

int ti^o^eq; 

}; 

Figure 15. The tran info Data Structure, 
structure that contains the union of all the language requests of MLDS 
(see Figure 16). The first request can originate from either a file or a terminal. 
The second field of tran^nfo is a pointer to the current transaction, set by LIL to 
tell the KMS the precise transaction to process next. The third field contains the 
number of transactions currently in the transaction list. This number is used for 
loop control when printing the transaction list to the screen, or when searching 
the list for a transaction to be executed. 

The second data structure used by LIL, req_info, is a union of the language 
requests of MLDS, and is shown in Figure 16. It serves a routing control func- 
tion, in that it routes a transaction request to the appropriate database language. 
In this thesis, we are concerned only with the the fourth field of this structure, 
which contains a pointer to the dap_req_info data structure (see Figure 17), each 
copy representing a Daplex user transaction. 

The third data structure used by LIL is named dap_req_jnfo. Each copy of 
this record represents a user transaction, and thus, is an element of the transac- 
tion list. The dap_req_info data structure is shown in Figure 17. The first field 



union req_mfo 

{ 

struct 

struct 

struct 

struct 

struct 

}; 



reljreq^nfo 
hie_req_info 
net_req_info 
dap_req_info 
ab req info 



*ri_rel_req; 
*ri ^ie^eq; 
*ri_net_req; 
*ri _dap_req; 
*ri ab req; 



Figure 16. The req info Data Structure. 
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struct dap^eq_info 

{ 

char *dap_req; 

int dap^eq_len; 
struct temp_str_info *dap_in_req; 

struct dap_req_mfo *dap_sub_req; 

struct dap_req^nfo *dap_next_req; 

}; 

Figure 17. The dap_req_info Data Structure, 
of this record, dap_req, is a character string that contains the actual Daplex 
transaction. The second field, dap_req^en, contains the length of the transac- 
tion. It is used to allocate the exact, and therefore minimal, amount of memory 
space for the transaction. The third field, dap_[n^eq, is a pointer to a list of 
character arrays that each contain a single line of one transaction. After all lines 
of a transaction have been read, the line list is concatenated to form the actual 
transaction, dap_req. If a transaction contains multiple requests, the fourth field, 
dap_sub_req, points to the list of requests that make up the transaction. In this 
case, the field dap^n_req is the first request of the transaction. The last field, 
dap^ext_req, is a pointer to the next transaction in the list of transactions. 

B. FUNCTIONS AND PROCEDURES 

LIL makes use of a number of functions and procedures in order to create the 
transaction list, pass elements of the list to KMS, and maintain the database 
schemas. We do not describe each of these functions and procedures in detail. 
Rather, we provide a general description of the LIL processes. 

1. Initialization 

The MLDS is designed to be able to accommodate multiple users, but in 
this version it is implemented to support only a single user. To facilitate the 
transition from a single-user system to a multiple-user system, each user possesses 
his own copy of a user data structure when entering the system. This user data 
structure stores all of the relevant data that the user may need during their ses- 
sion. All four modules of the language interface make use of this structure. The 
modules use many temporary storage variables, both to perform their individual 
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tasks, and to maintain common data between modules. The transactions, in user 
data language form, and mapped kernel data language form, are also stored in 
each user data structure. It is easy to see that the user structure provides conso- 
lidated, centralized control for each user of the system. When a user logs onto 
the system, a user data structure is allocated and initialized. The user ID 
becomes the distinguishing feature to locate and identify different users. The 
user data structures for all users are stored in a linked-list. When new users 
enter the system, their user data structures are appended to the end of the list. 
In our current environment there is only a single element on the user list. In a 
future environment, when there are multiple users, we simply expand the user list 
as described above. 

2. Creating the Transaction List 

There are two operations the user may perform. A user may define a 
new database or process Daplex requests against an existing database. The first 
menu that is displayed prompts the user to select the operation desired. Each 
operation represents a separate procedure to handle specific circumstances. The 
menu looks like the following: 

Enter type of operation desired 
(1) - load a new database 
(p) - process old database 
(x) - return to the operating system 
ACTION — > _ 

For either choice (i.e., 1 or p), another menu is displayed to the user 
requesting the mode of input. This input may always come from a data file. If 
the operation selected from the previous menu had been "p", then the user may 
also input transactions interactively from the terminal. The generic menu looks 
like the following: 
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Enter mode of input desired 

(f) - read in a group of transactions from a file 
(t) - read in transactions from the terminal 
(x) - return to the previous menu 
ACTION — > _ 

Note that the choice "t" would be omitted if the operation selected from the pre- 
vious menu had been to load a new database. Again, each mode of input selected 
corresponds to a different procedure to be performed. The transaction list is 
created by reading from the file or terminal, looking for an end-of-transaction 
marker or an end-of-file marker. These flags tell the system when one transaction 
has ended, and when the next transaction begins. When the list is being created, 
the pointers to access the list are initialized. These pointers, ti first req and 
ti_curr_req (as in Figure 15) are set to the first transaction read, in other words, 
to the head of the transaction list. 

3. Accessing the Transaction List 

Since the transaction list stores both DBDs and Daplex requests, two 
different access methods have to be employed to send the two types of transac- 
tions to the KMS. We discuss the two methods separately. In both cases, the 
KMS accesses a single transaction from the transaction list. It does this by read- 
ing the transaction pointed to by the request pointer, ti_curr_req, of the 
tran_mfo data structure (as in Figure 15). Therefore, it is the job of LIL to set 

this pointer to the appropriate transaction before calling KMS. 



a. Sending DBDs to KMS - When the user specifies the 
filename of DBDs (input from a file only), further 
user intervention is not required. To produce a new 
database, the transaction list of DBDs is sent to KMS 
via a program loop. This loop traverses the transaction 
list, calling KMS for each DBD in the list. 

b. Sending Daplex Requests to KMS - In this case, after 

the user has specified the mode of input, the user conducts 
an interactive session with the system. First, all Daplex 
requests are listed to the screen. As the requests are 
listed from the transaction list, a number is assigned to 
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each transaction in ascending order, starting with the number 
one. The number appears on the screen to the left of the 
first line of each transaction. Note that each transaction 
may contain multiple requests. Next, an access menu is 
displayed which looks like the following; 

Pick the number or letter of the action desired 

(num) - execute one of the preceding transactions 
(d) - redisplay the list of transactions 

(r) - reset the currency pointer to the root 

(x) - return to the previous menu 

ACTION — > _ 

Since Daplex requests are independent items, the order in which they are 
processed does not matter. The user has the option of executing any number of 
Daplex requests. A loop causes the menu to be redisplayed after any Daplex 
request has been executed so that further choices may be made. The selection 
"r" causes the currency pointer to be repositioned to the root of the entity- 
relationship schema so that subsequent requests may access the complete data- 
base, rather than be limited to beginning from a current position established by 
previous requests. 

4, Calling the KC 

As mentioned earlier, LIL acts as the control module for the entire 
system. When KMS has completed its mapping process, the transformed transac- 
tions have to be sent to KC to interface with the kernel database system. For 
DBDs, KC is called after all DBDs on the transaction list have been sent to 
KMS. The mapped DBDs have been placed in a mapped transaction list that 
KC is going to access. Since Daplex requests are independent items, the user 
should wait for the results from one Daplex request before issuing another. 
Therefore, after each Daplex request has been sent to KMS, KC is immediately 
called. The mapped Daplex requests are placed on a mapped transaction list, 
which KC may easily access. 

5. Wrapping-up 

Before exiting the system, the user data structure described in Chapter II 
(as in Figure 12) has to be deallocated. The memory occupied by the user data 
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structure is freed and returned to the operating system. Since all of the user 
structures reside in a list, the exiting user’s node has to be removed from the list. 
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V. THE KERNEL MAPPING SYSTEM (KMS) 



KMS is the second module in the Daplex mapping interface and is called 
from the language interface layer (LIL) when LIL has received Daplex requests 
input by the user. The function of KMS is to: (1) parse the request to validate 
the user’s Daplex syntax, (2) translate, or map, the request to an equivalent 
ABDL request, and (3) perform a semantic analysis of the current ABDL request 
generated relative to the request generated during a previous call to KMS. Once 
an appropriate ABDL request, or set of requests, has been formed, it is made 
available to the kernel controller (KC) which then prepares the request for execu- 
tion by MBDS. KC is discussed in Chapter VI. 

A. AN OVERVIEW OF THE MAPPING PROCESS 

From the description of the KMS functions above we immediately see the 
requirement for a parser as a part of the KMS. This parser validates the Daplex 
syntax of the input request. The parser grammar is the driving force behind the 
entire mapping system. 

1. The KMS Parser / Translator 

The KMS parser has been constructed by utilizing Yet- Another- Compiler 
Compiler (YACC) [Ref. 17]. YACC is a program generator designed for syntac- 
tic processing of token input streams. Given a specification of the input language 
structure (a set of grammar rules), the user’s code to be invoked when such struc- 
tures are recognized, and a low-level input routine, YACC generates a program 
that syntactically recognizes the input language and allows invocation of the 
user’s code throughout this recognition process. The class of specifications 
accepted is a very general one: LALR(l) grammars. It is important to note that 
the user’s code mentioned above is our mapping code that is going to perform the 
Daplex-to-ABDL translation. As the low-level input routine, we utilize a Lexical 
Analyzer Generator (LEX) [Ref. 18). LEX is a program generator designed for 
lexical processing of character input streams. Given a regular-expression 
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description of the input strings, LEX generates a program that partitions the 
input stream into tokens and communicates these tokens to the parser. 

The parser produced by YACC consists of a finite-state automaton with 
a stack that performs a top-down parse, with left-to-right scan and a one token 
look-ahead. Control of the parser begins initially with the highest-level grammar 
rule. Control descends through the grammar hierarchy, calling lower and lower- 
level grammar rules while searching for appropriate tokens in the input. As the 
appropriate tokens are recognized, some portions of the mapping code are 
invoked directly. In other cases, tokens are propagated upwards through the 
grammar hierarchy until a higher-level rule has been satisfied, and a further 
translation is performed. When all of the necessary lower-level grammar rules 
have been satisfied and control has ascended to the highest-level rule, the parsing 
and translation processes are complete. In Section B, we give an illustrative 
example of these processes. We also describe the subsequent semantic analysis 
necessary to complete the mapping process. The reader is reminded that Appen- 
dix C contains the code for our implementation, written in C. 

2. The KMS Data Structures 

KMS utilizes just two structures that are defined in the interface. Natur- 
ally, KMS requires access to the Daplex input request structure discussed in 
Chapter II, the dpi_dml_tran (see Figure 14 again) structure. However, the only 
two data structures to be discussed here are those unique to the KMS. 

Both of these structures are shown in Figure 18. The first of these, 
dap _kms_info, is a record that contains information, not of immediate use, that 
has been accumulated by the KMS during the grammar-driven parse. This 
record allows the information to be saved until a point in the parsing process 
where it may be utilized in the appropriate portion of the translation process. 
The first four fields in this record, point to the same structure, ident_list, the 
second structure of Figure 18, which temporarily holds a list of names for com- 
parison with the identifiers, subtype indicators, overlap_sub_node or 
overlap_ent^ode, and uniqueness identifiers, respectively. These names are those 
of attributes whose values are retrieved from the database. The remaining fields 
of dap kms info contain pointers to Daplex node structures previously discussed 
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struct dap_kms_i^nfo 

{ 



struct 

struct 

struct 

struct 

struct 

struct 

struct 

struct 

struct 

}; 



ident_list * 
ident_Hst * 
ident^ist * 
ident_Hst * 
der^on_node 
sub^on_node 
ent^on_node 
function_node 
ent value 



dki_temp j>tr; 
dki_id_ptr; 
dki_overfirst j>tr; 
dki^amel^tr; 
dki_der_non; 
dki_sub_non; 
dki_ent _non; 
dki^unct; 
*dki_ev jtr; 



struct ident_list 

{ 

thar il^ame [ENlength + l]; 
struct ident_list *il^ext; 

}; 



Figure 18. The KMS Data Structures. 



in Chapter II. The remaining field of ident^ist points to the next name in the 
list. At the conclusion of the mapping process, and before control is returned to 
LIL, all data structures unique to KMS that have been allocated during the map- 
ping process are freed. 

B. POSSIBLE FACILITIES PROVIDED BY AN IMPLEMENTATION 

As we reached this stage in the implementation, we were confronted with two 
problems. First, the deadline date for completion of this project was rapidly 
approaching, and second, the amount of code left to produce was nearly equal to 
the amount of code that we had provided to this point. In addition, due to the 
complexity of the entity-relationship model, the amount of code produced for the 
Daplex implementation had met or exceeded the amount of code for each of the 
implementations of DL/I, SQL, and CODASYL [Refs. 12, 13 and 19]. Accord- 
ingly, a decision was made to discontinue the implementation effort for this thesis 
and leave the remainder for another thesis. 
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In the remainder of this chapter, we discuss those Daplex facilities that may 
be provided by an implementation of the entity-relationship interface. We do not 
discuss the Daplex-to-ABDL translation in detail. Rather, we provide only an 
overview of the salient features of KMS. The interested reader is referred to 
Goisman [Ref. ll], for a detailed discussion of the Daplex-to-ABDL translation. 
User-issued requests may take two forms, either Daplex database definitions, or 
Daplex database manipulations. In the case of database manipulations, we also 
describe the semantic analysis necessary to complete the mapping process. 

1. Database Definitions 

When the user informs the LIL that the user wishes to create a new 
database, the job of the KMS is to build a entity-relationship database schema 
that corresponds to the database definition input by the user. The LIL initially 
allocates a new database identification node (ent_dbid_node shown in Figure 5) 
with the name of the new database, as input by the user. The LIL then sends 
the KMS a complete database description which takes the form of a Daplex data- 
base declaration as follows; 

DATABASE db_name IS 
[non_entity_type_declarations] 
entity_type_declarations 
[entity_type_constraints] 

END [db_name]; 

Where: 

db_name; is a valid identifier that is a unique 
name of the database being declared. 
non_entity_type_declarations: are declarations 
of string types, scalar types, and 
numeric constants. 

entity_type_declarations: are declarations of 
entity types, their functions, and 
generalization hierarchies. 
entity_type_constraints: define those properties 
of the declared entity type that must 
remain invariant under any operation on 
values of those types. 
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Figure 19. The University Database Schema 
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The non_entity_type_declarations, entity_type_declarations, and 
entity_type_constraints that form a database declaration can be intermixed in 
any order. However, all types must be declared (either completely or partially) 
before the name of the type can appear in another declaration, Accordingly, it is 
apparent that for each ent_dbid_node, a differing mix of ent_node(s), 
gen_sub^ode(s), ent^on^ode(s) and function_node(s) is possible. 

When LIL has forwarded all database definitions entered by the user, a 
completed database schema is the result. A completed database schema that uses 
the University database of Figure 3 is shown in Figure 19. The entity- 
relationship database schema, when completed, serves two purposes. First, when 
creating a new database, it facilitates the construction of the MBDS template 
and descriptor files. Secondly, when processing requests against an existing data- 
base, it allows a validity check of the entity, nonentity, and function names. It 
also serves as a source of information for the type checking. 

2. Database Manipulations 

When the user wishes LIL to process requests against an existing data- 
base, the first task of the KMS is to map the user’s Daplex request to an 
equivalent ABDL request. The only ABDL requests available are RETRIEVE, 
RETRIEVE-COMMON, INSERT, UPDATE and DELETE. To these ABDL 
requests KMS must map the Daplex operators ASSIGNMENT, INCLUDE, 
EXCLUDE, CREATE, DESTROY, MOVE and PROCEDURE _CALL. 

We will not discuss PROCEDURE_CALL as it includes utility pro- 
cedures such as print and cancel, and these operations are accommodated by the 
MLDS and ABDL operators. In addition, we will not discuss the RETRIEVE- 
COMMON statement of ABDL. Further, the mappings will be discussed at a 
level of abstraction that does not imply a specific coding implementation, but 
rather, a general algorithm that will accomplish the mapping. 

The first mapping that we will discuss is the CREATE mapping. A 
CREATE statement is used to create a new database entity. The structure for 
CREATE is shown in Figure 20. 

The function names and values are those function pairs that are associ- 
ated with a specific entity type or entity subtype. The entity types and entity 
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CREATE 



list of function names 
list of function values 
list of entity types and entity subtypes 
to be created 
pointer to RETRIEVE 
pointer to INSERT 
or 

pointer to INSERT 



pointer to INSERT 

Figure 20. The CREATE Data Structure. 

subtypes to be used to CREATE a new database entity are maintained in a list 
and the creation process continues as long as there are entity types or entity sub- 
types in the list. 

In general, the CREATE algorithm first determines if the new entity 
associated with the function pair in question is an existing supertype or a termi- 
nal type. If so, then the appropriate supertype/ terminal type previously associ- 
ated with the function pair is RETRIEVEd from the database, and the new 
entity type or entity subtype is INSERTed. Otherwise, the new entity type or 
entity subtype is simply INSERTed into the database. 

The next mapping that we will discuss is the DESTROY mapping shown 
in Figure 21. The function names and values for the DESTROY structure are 
the same as those associated with the CREATE structure, and in fact, these 
function pairs are the same for all of the subsequent Daplex mappings that we 
will discuss. The entity types and entity subtypes that are to be DESTROYed 
are maintained in a list and the destruction process continues as long as there are 
items in the list to be DESTROYed. 

The DESTROY algorithm only DELETEs entities, and further, only 
DESTROYS those entities that are not referenced by some database function. 
Therefore an entity is RETRIEVEd and a determination made as to whether the 
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DESTROY 



list of function names 
list of function values 
list of entity types and entity subtypes 
to be destroyed 
pointer to RETRIEVE 
pointer to DELETE 



pointer to DELETE 

Figure 21. The DESTROY Data Structure. 

entity is referenced by a database function. If so, then the DESTROY operation 
is aborted. If not, the entity is DELETEd and the process continues for the next 
entity to be DESTROYed until the list is empty. 

The FOR EACH structure is shown in Figure 22. The FOR EACH 
structure uses the set of database values as a pivot for the iteration process. 
Each element of the set of database values is paired with a set_expression for the 
execution of the loop. The set_expression values may be entites, function names 
or function values and provide the set of values over which the loop is iterated. 
Each RETRIEVE is accomplished on a set_expression value and an element of 

FOR EACH 

list of sets of database values 
set_expression values 
pointer to RETRIEVE 



pointer to RETRIEVE 
Figure 22. The FOR EACH Data Structure. 
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the set of database values acts as the second arguement for the operation to be 
carried out by FOR EACH. The RETRIEVES continue until the list of sets of 
database values is empty. 

The ASSIGNMENT statement structure is shown in Figure 23. The pur- 
pose of the ASSIGNMENT statement is to assign entity values to single-valued 
functions. 



ASSIGNMENT 

list of function names 
list of function values 
list of entity types and subtypes 
of each function 
pointer to RETRIEVE 
or 

pointer to RETRIEVE 
pointer to RETRIEVE 
pointer to RETRIEVE 



pointer to RETRIEVE 
REPEAT 

pointer to RETRIEVE 
or 

pointer to RETRIEVE 
pointer to RETRIEVE 
pointer to RETRIEVE 
pointer to RETRIEVE 



pointer to RETRIEVE 
pointer to RETRIEVE 
pointer to RETRIEVE 
pointer to UPDATE 



pointer to UPDATE 

Figure 23. The ASSIGNMENT Data Structure. 
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purpose of the ASSIGNMENT statement is to assign entity values to single- 
valued functions. To accomplish this, the ASSIGNMENT algorithm searches 
through the database by RETRIEVing and comparing the function to be 
assigned to all of the functions in the database. In this case,, it is assumed that 
the function in question exists and can be found. 

The search is accomplished by going first to a supertype and comparing 
the functions associated with each of the subtypes until a match is found. If no 
match is found, then each subtype is treated as a supertype and the search con- 
tinues downward through the tree until the function is found or a terminal type 
is reached. 



INCLUDE 

list of function names 
list of function values 
list of entity types and subtypes 
of each function 
pointer to RETRIEVE 
or 

pointer to RETRIEVE 
pointer to RETRIEVE 
pointer to RETRIEVE 



pointer to RETRIEVE 
pointer to INSERT 



pointer to INSERT 

Figure 24. The INCLUDE Data Structure. 

Once the function is found, the search begins for all of the function 
values. This searching process is similar to the process for the function lookup 
and repeats until the desired value associated with the function in question is 
found. Once found, the value is then UPDATEd. The entire process continues 
until the list of functions and values to be assigned is empty. 
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The INCLUDE statement structure is shown in Figure 24. The purpose 
of the INCLUDE statement is to add either a single value or a set of values to a 
set-valued function. It functions in a manner similar to the ASSIGNMENT 
statement in that the search is accomplished by going first to a supertype and 
then comparing the functions associated with each of the subtypes until a match 
with the desired function is found. If no match is found, then each subtype is 
treated as a supertype and the search continues downward through the tree until 
the function is found or a terminal type is reached. Once the function is found, 
the single value or set of values that the user wishes to INCLUDE is INSERTed. 

EXCLUDE 

list of function names 
list of function values 
list of entity types and subtypes 
of each function 
pointer to RETRIEVE 
or 

pointer to RETRIEVE 
pointer to RETRIEVE 
pointer to RETRIEVE 



pointer to RETRIEVE 
pointer to DELETE 



pointer to DELETE 

Figure 25. The EXCLUDE Data Structure. 

The EXLUDE statement structure is almost identical to the INCLUDE 
statement structure. As can be seen from Figure 25, the only difference is that 
once the desired function is found the value is DELETEd instead of INSERTed. 

The final structure that we will discuss is that of the MOVE statement, 
shown in Figure 26. The purpose of the MOVE statement is to change the sub- 
types to which an entity belongs. The MOVE statement algorithm first performs 
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MOVE 



list of function names 
list of function values 
list of entity types and subtypes 
to be moved 
pointer to RETRIEVE 
pointer to RETRIEVE 
pointer to DELETE 
pointer to RETRIEVE 
pointer to INSERT 



pointer to INSERT 

Figure 26. The MOVE Data Structure. 

a RETRIEVE from the database using functions in entity valued expressions as a 
search key, or just using the entity valued expressions if the associated functions 
are not given. When the entity valued expressions are located, the corresponding 
functions are then searched for and RETRIEVEd. The entity valued expression 
is then DELETEd from its current location in the database and the new entity to 
which the entity valued expression is to be associated is RETRIEVEd. The 
entity valued expression and its associated function is then INSERTed into the 
new location. 
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VI. CONCLUSION 



In this thesis, we have presented a partial specification and implementation 
of a Daplex language interface . This is one of four language interfaces that the 
multi-lingual database system will support. When complete, the multi-lingual 
database system will be able to execute transactions written in four well-known 
and important data languages, namely, SQL, DL/I, Daplex, and CODASYL. In 
our case, we support Daplex transactions with our language interface by way of a 
LIL and KMS, and have left the production of a Daplex KC and KFS for a 
future thesis. Related theses by Benson and Wentz, Kloepping and Mack, and 
Emdi [Refs. 12, 13 and 19] have examined the specification and implementation 
of the DL/I, SQL and CODASYL-DML language interfaces, respectively. All of 
these works are a part of the ongoing research being conducted at the Laboratory 
for Database Systems Research, Naval Postgraduate School, Monterey, 
California. 

The need to provide an alternative to the development of separate 
stand-alone database systems for specific data language models has been the 
motivation for this research. In this regard, we have first demonstrated the feasi- 
bility of a multi-lingual database system (MLDS) by showing how a software 
Daplex language interface can be constructed. 

A major goal has been to design a Daplex-to-MBDS interface without 
requiring any change be made to MBDS or ABDL. Our partial implementation 
may be completely resident on a host computer or the controller. All Daplex 
transactions will be performed in the Daplex interface. MBDS continues to 
receive and process transactions written in the unaltered syntax of ABDL. In 
addition, our implementation has not required any change to the syntax of 
Daplex. The interface will be completely transparent to the Daplex user as well 
as to the MBDL. 

In retrospect, our level-by-level, top-down approach to the design of the 
interface has been a good choice. This implementation methodology has been the 
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most familiar to us and proved to be relatively efficient in time. In addition, 
this approach permits follow-on programmers to easily maintain and modify 
(when necessary) the code. Subsequently, they will know exactly where we 
have stopped and where they should begin because we have included many of 
the lower-level stubs. Hence, it is an easy task to fill in these stubs with code. 

To our great disappointment we have not been able to complete the imple- 
mentation. The primary reason for our failure has been the complexity of the 
entity-relationship model and the Daplex language. This complexity has been 
directly responsible for our underestimation of the amount of code necessary for 
the Daplex interface implementation. To date, we have produced an amount of 
code at least equal to each of the other complete implementations, and are faced 
with producing an equal amount in order to complete the implementation. 

However, we have shown that a Daplex interface can be implemented as part 
of a MLDS. We have provided a partial software structure to facilitate this 
interface, and we have developed actual code for implementation. The next step 
is to complete the development of the Daplex interface. When complete, this 
interface can be integrated with the other implementations and tested as a whole 
to determine how efficient, effective, and responsive it can be to a users’ needs. 
The results may be the impetus for a new direction in database system research 
and development. 
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APPENDIX A 



DAPLEX DATA STRUCTURES 



/* this is a list of the data structures for the daplex project * / 



union dbid_node 

/* Union definition for the database. There is a common */ 
/* database node definition that spans the four types of */ 
/* language interfaces. Abbr: rel(ational), hie(archical),*/ 
/* net(work), and entity-relationship. */ 

{ 

struct rel_dbid^ode *dn_rel; 
struct hie^dbid^ode *dn^ie; 

struct net_dbidjode *dn^et; 

struct ent_dbid^ode *dn_dap; 

}; 



struct ent_dbid^ode 

I* structure def for each entity-relationship dbid node */ 

{ 



char 


edn _name[DBNLength + l]; 


struct 


ent non node 


*edn jonentity; 


int 


edn^um^onent; number of nonentity types */ 


struct 


ent jode 


*edn entity; 


int 


edn^um_ent; 


/* number of entity types */ 


struct 


gen_subjnode 


*edn_^ubptr; 


int 


edn_num_gen; 


/* number of gen_subtypes */ 


struct 


subjon node 


*edn^onsubptr; 


int 


edn _numjonsub; /* number of nonentity subtypes */ 


struct 


der non node 


*edn _nonderptr; 


int 


edn ^um_der; 


/* nmbr or nonentity derived types * ^ 


struct 


ent_dbid ^ode 


*edn^ext_db; 



}; 



struct ent_node 

/* structure definition for each entity node */ 

{ 

char en^ame[ENLength -f- l]; 

int en_num_funct; /* number of assoc, functions */ 
int en_terminal; /* if true (=l) it is a terminal type */ 
struct functionjode *en_ftnptr; 
struct ent_node *en_next_ent; 

}; 
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struct gen_sub^ode 

/* structure def for each generalization (supertype/subtype) node */ 

{ 

char gsnjiame[ENLength H- l]; 

int gsnjium_funct; /* number of assoc, functions*/ 

int gsn_terminal; /* if true (=1) it is a terminal type */ 

struct overlap_ent jode *gsn_entptr; /* ptr to entity supertype */ 

int gsn _num_ent; /* number of entity supertypes */ 

struct functionjiode *gsn^tnptr; 

struct overlap_subjiode *gsn_subptr; /* ptr to subtype supertype */ 
int gsn jum_sub; /* number of subtype supertypes */ 

struct gen_sub^ode *gsn^ext_genptr; 

}; 



struct ent _non^ode 

/* structure def for each base-type nonentity node */ 

{ 

char enn^ame[ENLength H- l]; 

char enn_type; /* either i(nteger), s(tring), 

f(loat), e(numeration), or b(oolean) */ 
int enn_totaMength; /* max length of base-type value */ 
int enn_range; /* true or false depending on whether 
there is a range. If a range exists, 
there must be two entries into ent_yalue */ 
int enn^um_values; /* number of actual values */ 
struct ent_value /*enn_yalue; /* actual value of base-type */ 
int enn_constant; /* boolean to refelect constant value */ 
struct ent jon^ode *enn^ext^ode; 

}; 



struct sub^on^ode 

/* structure def for each subtype nonentity node */ 

{ 

char snn^ame[ENLength H- l]; 

char snn_type; /* either i(nteger), s(tring), 

f(loat), e(numeration), or b(oolean) */ 
int snn_totaMength; /* max length of subtype value */ 
int snn^ange; /* true or false depending on whether 
there is a range. If a range exists, 
there must be two entries into ent_yalue */ 
int snn jum_values; /* number of actual values */ 

struct ent_value *snn_value; /* actual value of subtype * / 
struct sub _non_node *snn^ext jode; 

}; 
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struct der _non^ode 

/* structure def for each derived type nonentity node */ 

{ 

chax dnn jame[ENLength -h 1]; 

char dnn_type; /* either i(nteger), s(tring), 

f(loat), e(numeration), or b(oolean) */ 
int dnn_total_length; /* max length of derived type value * / 
int dnn^ange; /* true or false depending on whether 
there is a range. If a range exists, 
there must be two entries into ent_yalue */ 
int dnn _num_yalues; /* number of actual values */ 

struct ent_value *dnn_value; /* actual value of derived type */ 
struct der^on^ode *dnn_next _node; 

}; 



struct function^ode 

/* structure definition for each function type declaration */ 

{ 

chax fn jame[ENLengthH“l]; 

chax fn_type; /* either f(loat), i(nteger), s(tring), 

b(oolean), or e(numeration) * / 
int fn^ange; /* Boolean if range of values */ 

int fn_total_length; /* max length */ 
int fn_num_value; /* number of actual values * / 
struct ent_yalue *fn_yalue; /* actual value */ 
struct ent^ode *fn_entptr; /* ptr to entity type */ 
struct gen^ub jode *fn^ubptr; j* ptr to entity subtype */ 
struct ent^on_node *fn^onentptr; /* ptr to nonentity type * / 
struct sub^on^ode *fn _nonsubptr; /* ptr to nonentity subtype */ 
struct der^on_node *fn _nonderptr, /* ptr to nonentity dertype */ 
int fn_entnull; /* initialized false set true for no value * / 
int fn_unique; /* init false - unique if true */ 
struct function_node *fnjnextJ[ntptr; 

}; 



struct 



user^nfo 

/* This structure is used to maintain information on all of the */ 
/* current users of the paxticuleir interface. The interface type * / 
/* is determined by the li^nfo structure. * / 

{ 



cheir ui_uid[UIDLength -h l]; /* The user id * / 

union li^nfo ui_li_type; /* li is for language interface */ 

struct user^nfo *ui _next_user; 

}; 
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union IMnfo 

/* This union is used to choose a particular data structure. * / 
/* The data structure chosen is interface dependent, i.e., * / 

/* li^ql is for the relational interface, li_dli is for the * / 

/* hierarchical interface and li_dnil is for the network int. */ 
/* and li_dap is for the entity relationship interface. * / 

{ 

struct sqMnfo li_?ql; 

struct dli^nfo li _dli; 

struct dmMnfo li_dml; 
struct dap^nfo li_dap; 

}; 



struct dap^nfo 



/* The structure for info about the daplex request for a user */ 


X 

struct 


curr_db_|nfo 


dpi_curr_db; /* The current user */ 


struct 


file^nfo 


dpi _file; /* The dap files of request */ 


struct 


tran info 


dpi dml tran; /* The dml transactions 


struct 


ddl info 


*dpi ddl files; /* The abdl ddl files */ 


int 


dap_operation; /* The operation to be performed */ 


int 


dap answer; 




int 


dap error; 




int 


dap buff count; 


union 


kms info 


dpi Jcms_data; 


union 


kfs_info 


dpi kfs data; 


union 


kc info 


dpi kc data; 



}; 
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APPENDIX B 



THE STORAGE AND RETRIEVAL MODULES 



A. STORAGE 



/* this file is savefree.c */ 



^include <stdio.h> 

^include "flags. deP’ 

^include "licommdata.der' 

^include "struct. deP 
include "dap. ext" 

strfr_dap_db_list() 

{ 

/* begin strfr_dap_db_list */ 

struct ent_dbidjiode *db_ptr; /* ptr to the database list */ 
struct ent_non^ode *non _ent_ptr; /* ptr to the nonentity node */ 
struct ent_yalue *entval_ptr; /* ptr to the entity value node */ 
struct subjion jode *subnon__ptr; /* ptr to nonent subtype node */ 

struct der^on _node "‘'dernon_ptr; /* ptr to derived subtype node */ 

struct ent^ode *ent jiodej)tr; /* ptr to the entity node */ 

struct gen_sub jode *gen_ptr; /* ptr to the gen subtype node * / 

struct overlap _ent^ode *overlapent _ptr; /* ptr to the entity subtype */ 
struct overlap_subjiode *overlapsub _ptr; /* ptr to the term subtype */ 
struct functionjiode *func_ptr; /* ptr to the function node */ 

FILE *dapjid; 

char temp_str[NUMDIGIT -h l]; 



/* this function saves the entity/functional schema */ 
/* back to a file and frees the list it occupied */ 



#iflef EnExFlag 

printf( "Enter strfr_dap_db^ist"); 

#endif 



if ((dapjld = fopen (DAPDBSFname, "w")) == NULL) 
{ /* begin if NULL */ 

printf("Unable to open %s", DAPDBSFname); 
ring_the_bell(); 



#iflef EnExFlag 

printf ( " Exit 1 strfr_dap_db^ist " ) ; 

#endif 

return; 

} /* end if NULL */ 



58 



db_ptr = dbs_dap ^ead_ptr.dn_dap; 
while (db_j)tr != NULL) 

{ /* the database is stored to the file here */ 

wr_ent _dbidj[iode(dap^d,db_ptr); 
non ent ptr = db_ptr -> edn_nonentity; 

while (non_ent_ptr != NULL) 

{ /* begin while non_ent_ptr 1= NULL */ 

proc_ent _non^ode(dap^d, non_ent_ptr); 
non_ent_ptr = non_ent_ptr -> enn^ext _node; 

} /* end while non _ent_ptr != NULL */ 

ent_node_ptr = db_ptr -> edn_entity; 
num_to_str(dbjptr -> edn_num_ent, temp_str); 
writestr(dap^d, temp_str); 

while (ent^ode_ptr != NULL) 

{ /* begin while ent^ode_ptr != NULL) */ 

wr_ent^ode(dap^d, ent_node_ptr); 
ent_node_ptr = ent^ode_ptr -> en_next_ent; 

} /* end while ent^odejptr != NULL */ 

gen_ptr = db_ptr -> edn _subptr; 
num_to _str(db_ptr -> edn_num_gen, temp^str); 
writestr(dap^d, temp_str); 

while (gen_ptr != NULL) 

{ /* begin while gen_ptr != NULL */ 

wr_gen _sub^ode(dap_fid,gen_ptr); 
gen_ptr = gen_ptr -> gsn^ext_genptr; 

} /* end while gen_ptr != NULL */ 

gen_ptr = db_ptr -> edn _subptr; 

while (gen_ptr != NULL) 

{ /* begin while gen_ptr != NULL */ 

num_to _str(gen_ptr -> gsn^um_ent, temp_str); 
writestr (dap^d, temp_str); 
overlapent_ptr = gen_ptr -> gsn_entptr; 

while( overlapent_ptr != NULL) 

{ /* begin while overlapent_ptr != NULL */ 

writestr(dap^id, overlapent_ptr -> oen^ame -> en ^ame) 
overlapent_ptr = overlapent_ptr -> oen^ext_name; 

} /* end while overlapent _ptr != NULL */ 
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num_to_str(gen_ptr -> gsn_num _sub, temp_str); 
writestr(dap _fid, temp _str); 
overlapsub_ptr = gen_ptr -> gsn_subptr; 

while (overlapsub_ptr != NULL) 

{ /* begin while overlapsub_ptr != NULL */ 

writestr(dap _fid, overlapsub_ptr -> osn^ame -> gsn_name); 
overlapsubjptr = overlapsub_ptr ->osn jext^ame; 

} /* end while overlapsub_ptr != NULL */ 

gen_ptr = gen_ptr -> gsn^ext_genptr; 

} /* end while genjptr != NULL */ 

/* Process the sub non nodes */ 

subnon_ptr = db_ptr -> edn_nonsubptr; 
num_to^tr (dbjptr -> edn^um^onsub, temp^tr); 
writestr (dap _fid, temp_str); 

while (subnon_ptr != NULL) 

{ /* begin while subnonjptr <> NULL */ 

proc _sub jon jode (dap ^d, subnonjptr); 
subnon_ptr = subnonjptr -> snn jiext jiode; 

} /* end while subnon_ptr <> NULL */ 



/* Process the derived nodes */ 

dernon_ptr = dbjptr -> edn_nonderptr; 
num_to_str(db jPtr -> ednjium_der, temp_str); 
writestr (daPjfid, temp_str); 

while (dernonj)tr != NULL) 

{ j* begin while dernon_ptr <> NULL */ 

proCjderjion jiode (dap _fid,dernon_j)tr); 
demon jPtr = demon j)tr -> dnnjiextjiode; 

} /* end while dernon^ptr <> NULL */ 

/* Process the Ent function nodes */ 

ent jiodCjPtr = db j)tr -> edn ^entity; 

while (ent jiodejptr != NULL) 

{ /* begin while entjiodejptr != NULL */ 

wr _all_ent jiode(dap J[id, entjiodejptr); 
ent jiodej)tr = ent jiode j)tr -> en jextjnt; 

} /* end while entjiodejptr != NULL */ 
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gen_ptr = db_ptr -> edn_subptr; 

while {gen_ptr != NULL) 

{ /* begin while gen_ptr != NULL */ 

func_ptr = gen_ptr -> gsn^tnptr; 

while (func_ptr != NULL) 

{ /* begin while func_ptr != NULL */ 

proc J|unction^ode(dap_fid,func_ptr); 
gen_ptr->gsn_ftnptr = func_ptr->fn_next_Jntptr; 
free_Junction_jiode(func_ptr); 
func_ptr = gen_ptr -> gsn_ftnptr; 

} /* end while func_ptr != NULL */ 

gen_ptr = gen_ptr -> gsn jext^enptr; 

} /* end while gen_ptr != NULL */ 

db_ptr = db_ptr -> edn_jiext_db; 

} /* end while db_ptr != NULL */ 

putc(’$’, dap^id); 
putc(”, dap_fid); 



#iflef EnExFlag 

printf(”Exit strfr_dap_db_Jist"); 

#endif 

} /* end strfr_dap_db^ist */ 
wr_ent_dbid jode( ffid, db_ptr) 

FILE *ffid; 

struct ent_dbid_jiode *db_ptr; 

{ 

char temp_str[NUMDIGIT -H l]; 

/* this function writes the database */ 
/* structure’s contents to the save file */ 

#iflef EnExFlag 

printf(*^Enter wr_ent_dbid ^ode”); 

#endif 



writestr(ffid, db_ptr -> edn jame); 
num_to_str(db_ptr -> edn^um ^onent, temp_str); 
writestr{ffid, temp_str); 

#iflef EnExFlag 

printf(”Exit wr_ent_dbid ^ode"); 

#endif 

} /* end wr_ent_dbid ^ode */ 
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procjent _non _node(fid, non_ptr) 

FILE *fid; 

struct ent _non _node *non_ptr; 

{ I* begin proc_ent_non _node */ 

struct ent_yalue *val_ptr; 

char temp^trjNUMDIGIT -h 1]; 



^iflef EnExFlag 

printf("Enter procjent jon ^ode’*); 

#endif 



writestr(fid, non_ptr -> enn _name); 
putc(non _ptr **> enn_type, fid); 
putc(”, fid); 

num_to _str(non_ptr -> enn_total_l^ength, temp _str); 
writestr(fid, temp _str); 

num_to _str(non_ptr -> enn^ange, temp _str); 
writestr(fid, temp_str); 

num_to _str(non_ptr -> enn_constant, temp_str); 
writestr(fid, temp_str); 

num_to _str(non_ptr -> enn _num_values, temp _str); 

writestr(fidj temp_str); 

val_ptr = non_ptr -> enn_yalue; 

while (val_ptr != NULL) 

{ /* begin while valjtr <> NULL */ 

writestr(fid,val_ptr -> ev_yalue); 
val_ptr = val_ptr -> ev _next_value; 

} /* end while valjtr <> NULL */ 

^iflef EnExFlag 

printf(*'Exit proc_ent _non _node**); 

^endif 



} /* end proc_ent _non _node * / 

wr_ent _node(fid,ent_ptr) 

FILE *fid; 

struct ent _node *ent_ptr; 

{ /* begin wr_ent jnode * / 

char temp^tr[NUMDIGIT + l]; 

#iflef EnExFlag 

printf(”Enter wr_ent _node”); 

#endif 



writestr(fid, ent_ptr -> en _name); 
num_to_str(ent_ptr -> en _num^unct, temp _str); 
writestr(fid, temp_str); 

num_to _str(ent_ptr -> en_terminal, temp _str); 
writestr(fid, temp ^tr); 



#iflef EnExFlag 
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:#endif 



printf("Exit wr_ent^ode"); 
} /* end wr_ent^ode */ 



wr_£en_sub^ode(rid,gs_ptr) 

FILE *rid; 

struct gen_sub_node *gs_ptr; 

{ /* begin wr_gen_sub _node * / 
char temp_str[NUMDIGIT -f l]; 

=^iflef EnExFlag 

printf("Enter wr_gen_sub^ode"); 

#endif 



writestr(rid,gs_ptr -> gsn ^ame); 
num_to_str(gs_ptr -> gsn jum_funct, temp_str); 
writestr(fid, temp _str); 

num_to_str(gs_ptr -> gsn_terminal, temp_str); 
writestr(fid, temp^str); 



^ifief EnExFlag 

printf("Exit wr_gen_sub _node”); 

#endif 

} /* end wr_gen_sub^ode */ 
proc_sub^on jiode(fid, sub_j>tr) 

FILE *fid; 

struct sub^on^ode *sub_ptr; 

{ /* begin proc_sub_non^ode * / 

FILE *fid; 

struct ent_yalue *val_ptr; 

char temp_str[NUMDIGIT + l]; 



=^iflef EnExFlag 

printf( "Enter proc _sub^on_node"); 

^endif 



writestr(fid, sub_ptr -> snn_name); 
putc (sub_ptr -> snn_type, fid); 
putc(”, fid); 

num_to_str(sub_ptr -> snn_totaMength, temp _str); 
writestr(fid,temp _str); 

num_to_str(sub_ptr -> snn^ange, temp^str); 
writestr(fid, temp _str); 

val_ptr = sub_ptr -> snn_yalue; 

while (val_ptr != NULL) 

{ /* begin while val_ptr <> NULL */ 

writestr(fid, val_ptr -> ev_yalue ); 
val_ptr = val_ptr -> ev^ext_yalue; 

} /* end while val_ptr <> NULL * / 
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EnExFlag 

printf(”Exit proc_sub^on^ode“); 

#endif 

} /* end proc _sub ^on^ode */ 
proc_der jon jode ( fid , der_ptr ) 

FILE *fid; 

struct der^on^ode *der_ptr; 

{ /* begin proc_der^on_node */ 

struct ent_yalue *val_ptr; 

char temp _str[NUMDIGIT -f- l]; 

#iflef EnExFlag 

prin tf ( "Enter proc_der_non jiode" ) ; 

#endif 



writestr(fid, der_ptr -> dnn jame); 
putc (der_ptr -> dnn_type, fid); 
putc(”, fid); 

num_to_str(der_ptr -> dnn_total_length, temp __str); 
writestr(fid, temp_str); 

num_to _str(der_ptr -> dnn^ange, temp_str); 

writestr(fid, temp _str); 

valjtr = der_ptr -> dnn_value; 

while (val_ptr != NULL) 

{ /* begin while val_ptr <> NULL */ 

writestr(fid, valjptr -> ev_yalue); 
val_ptr = val_ptr -> ev^ext_yalue; 

} /* end while val_ptr <> NULL * / 

^iflef EnExFlag 

printf("Exit proc_der^on _node"); 

#endif 



} /* end proc_der^on^ode */ 

wr _all_ent jode(fid,ent_ptr) 

FILE *fid; 

struct ent jode *ent_ptr; 

{ /* begin wr _all_ent^ode */ 

struct function^ode *funct_ptr; 
char temp_str[NUMDIGIT -h ij; 



#ifief EnExFlag 

printf( "Enter wr _all_ent ^ode"); 

#endif 



funct_ptr — ent_ptr -> en^tnptr; 

while (funct_ptr != NULL) 

{ /* begin while funct_ptr <> NULL */ 

proc^unction jiode(fid,funct_ptr) ; 
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ent_ptr -> en_ftnptr = funct_ptr -> fn^ext^ntptr; 

free_functionjiode(funct_ptr); 

funct_ptr = ent_ptr -> en^tnptr; 

} /* end while funct_ptr <> NULL */ 

#iflef EnExFlag 

printf(”Exit wr _all_ent jode”); 

^endif 

} /* end wr _all_ent _node */ 



proc^unction_node(fid,fptr) 

FILE *fid; 

struct functionjode *fptr; 

{ /* begin proc^unction^ode */ 

struct ent_yalue *val_ptr; 

struct ent jode *eptr; 
struct gen_subjode *gsptr; 

struct ent_nonjode *enptr; 

struct sub^on^ode *snptr; 

struct der^onjiode *dnptr; 

char temp_str[NUMDIGIT + l); 



#iflef EnExFlag 

printf(”Enter proc^unction^ode”); 

#endif 



writestr(fid, fptr -> fnjiame); 
putc(fptr -> fn_type, fid); 
putc(’\ fid); 

num_to_str(fptr -> fn^ange, temp^str); 
writestr(fid, temp_str); 

num_to_str(fptr -> fn_totalJ[ength, temp_str); 
writestr(fid, temp_str); 

num_to_str(fptr -> fn jum^value, temp_str); 
writestr(fid, temp_str); 
val_ptr = fptr -> fn_value; 

while (val_ptr != NULL) 

{ /* begin while valjtr <> NULL */ 

writestr ( fid, val_ptr -> ev_yalue); 
val_ptr = val_ptr -> ev jext_yalue; 

} /* end while val_ptr <> NULL */ 

eptr = fptr -> fn^entptr; 

if(eptr != NULL) 
writestr(fid, eptr -> enjname); 
else 

writestr(fid, ”"**); 
gsptr = fptr -> fn_subptr; 
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if(gsptr != NULL) 

writestr(fid, gsptr -> gsn^ame); 

else 

writestr(fid, 

enptr = fptr -> fn ^onentptr; 

if(enptr != NULL) 
writestr(fid, enptr -> enn^ame); 
else 

writestr(fid, *'^"); 

snptr = fptr -> fn jonsubptr; 

if(snptr != NULL) 
writestr(fid, snptr -> snn^ame); 
else 

writestr(fid, """); 

dnptr = fptr -> fn jonderptr; 

if(dnptr != NULL) 
writestr(fld, dnptr -> dnn jame); 
else 

writestr(fid, "^"); 

num_to_str(fptr -> fn_entnull, temp _str); 
writestr(fid, temp_str); 

num_to _str(fptr -> fn_anique, temp _str); 
writ estr (fid, temp _str); 



#iflef EnExFlag 

printf("Exit proc^unction^ode"); 

#endif 

} /* end proc^unction^ode */ 



free^unction ^ode(func_ptr) 

struct functionjiode *func_ptr; 
{ /* begin free_function^ode */ 

#iflef EnExFlag 

printf(’*Enter free^unction jode"); 

#endif 



strcpy(func_ptr -> fn ^ame, ** **); 
func_ptr -> fn_type = ’ 
func_ptr -> fn^ange = 0; 
func_ptr -> fn_totaMength = 0; 
func_ptr -> fn^um_value = 0; 
func_ptr -> fn_yalue = NULL; 
func_ptr -> fn_entptr = NULL; 
func_ptr -> fn _subptr = NULL; 
func_ptr -> fn jonentptr = NULL; 
func_ptr -> fn jonsubptr = NULL; 
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func_ptr-> fn _nonderptr = NULL; 
func _ptr -> fn_entnull = 0; 
func _ptr -> fn_unique = 0; 
func_ptr -> fn_next^ntptr = NULL; 

EnExFlag 

printf(”Exit free^unction^ode'*); 

#endif 

} /* end free_function jode */ 



B. RETRIEVAL 



/* This file is makelist.c */ 



^include <stdio.h> 

^include ^fiags.def* 

^include ’*licommdata.deP' 

^include ”struct.def 
^include ”dap.ext” 

creat_dap_db^ist 0 

{ 

struct ent_dbid^ode *new_db_ptr, *db_ptr; /* ptr to the enty-relationp node */ 

struct ent_non jode *new_non_ent _ptr, *nonjent_ptr; /* ptr to nonenty node */ 

struct ent_yalue *new_entval_ptr, *entval_ptr; /* ptr to the enty value node */ 

struct subjon^ode *new_subnon_ptr, *subnon_ptr; /*ptr to sub jonenty node */ 

struct ent_node *new_ent ^odejtr, *ent jode_ptr; /* ptr to the entity node */ 

struct gen sub node *new gen ptr, *gen_ptr; /* ptr to gen super,subtype node */ 

struct overlap_ent_node *new_overlapent_ptr, *overlapent_ptr; 

struct overlap^ub_node *new_overlapsub_ptr, *overlapsub_ptr; 

struct function^ode *new_func_ptr, *func_ptr; /* ptr to the function node */ 

struct der jon_node *new_dernon_ptr, *dernon_ptr; /* ptr to nonent der node */ 

int ed_count, ent_count, funct_count, num_yal; /* counters */ 

int gen_sub_count, super_count, sub_super _count; /* counters * / 

int non_sub_count, non_der_count, enum_count; /* counters */ 

int done^ag, first_db, first^onnode; /* booleans */ 

int first_enum, firstjriode, firstj^unc; /* booleans */ 

int first_value, first_gen_sub, first_super; /* booleans */ 

int first^ub_super, first_non^ub; /* booleans */ 

int first^on_der; /* boolean */ 

struct ent_dbid _node *rd_ent_dbid jiode(); 

struct entj[ionj[iode *rd_ent _non^ode(); 

struct ent_yalue *rd_ent_yalue(); 

struct sub^on^ode *rd_subjon jode(); 

struct ent_node *rdjent jode(); 

struct gen_subj[iode *rd_gen_sub ^ode(); 

struct overlap_ent jode *rd _overlap_ent^ode(); 

struct overlap_sub ^ode *rd_overlap^ub _node(); 

struct functionjode *rd^unction jode(); 

struct derjonjode *rd_derj[ion^ode(); 

FILE *dapjid; 

char temp_str[NUMDIGIT -h 1); 
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/* This function retrieves and recreates the schema from the stored file */ 
#iflef EnExFlag 

printf (”Enter create_dap_db_list^^); 

#endif 

if ( (dapjid = fopen( DAPDBSFname, *’r”) ) == NULL) 

{ 

printf (’’Unable to open file %s”, DAPDBSFname); 
ring_the_bell(); 

f^iflef EnExFlag 

printf (”Exitl creat_dap_db_list"); 
f^endif 

return; 

} 

done _flag = FALSE; 

first_db = TRUE; 

while ( done ^ag != TRUE ) 

{ 

/* the schema nodes are allocated and filled here */ 
new_db_ptr = rd_ent_dbidjnode( dap jfid, &done _fiag); 
if ( done Jlag != TRUE ) 

{ 

if ( first _db == TRUE ) 

{ 

/* special case of accessing the first entity relationship */ 
dbs_dap _head_ptr.dn_dap = new_db_ptr; 
db_ptr = new_db_j)tr; 
first_db = TRUE; 

} 

else 

{ 

db_ptr- >edn^ext_db = new db ptr; 
db_ptr = new_db_j)tr; 

} 

first_nonnode = TRUE; 

ed_count = db_ptr->edn_num jonent; 

while ( ed_count != 0 ) 

{ 

/* the nonentity nodes are allocated and filled here */ 
new^on_ent_ptr = rd_ent^on_node(dap_fid); 
if ( first^onnode == TRUE ) 

{ 

/* special case for first nonentity */ 
db_ptr->edn_nonentity = new^on_ent_ptr; 
non_ent_ptr = new jon_ent jptr; 
first^onnode = FALSE; 

} 
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else 

{ 

non_ent_ptr->enn jext_node = new_non_ent_ptr; 
non_ent_ptr = new jon_ent_ptr; 

} 

first_enum = TRUE; 

enum_count = non_ent_ptr->enn jum_values; 
while ( enum_count != 0 ) 

{ 

/* the actual value nodes are allocated and filled here */ 
new_entval_ptr = rd_ent_yalue(dap^idj 

non_ent_ptr->enn_totaMength); 
if ( first_enum == TRUE ) 

{ 

j'*' special case of first actual value */ 
non_ent_ptr->enn_yalue = new_entval_ptr; 
entval_ptr — new_entval_ptr; 
first_enum = FALSE; 

} 

else 

{ 

entval_ptr->ev^ext_yalue = new_entval_ptr; 
entval_ptr = new_entval_ptr; 

} 

— enum_count; 

} j'^ end value loop */ 

— ed_count; 

} /* end base type nonentity loop */ 

first jode = TRUE; 
readstr(dap ^d,temp_str); 

db_ptr->edn jium_ent = str_tojium(temp_str); 
ent_count — db_ptr->edn_num_ent; 
while ( ent_count != 0 ) 

{ 

j* the entity nodes are allocated and filled in here * j 
new_ent_node_ptr = rd_ent^ode(dap _fid); 
if (first jode == TRUE ) 

{ 

/* special case of first entity node * j 
db_ptr->edn_entity = new_ent^odejptr; 
ent^ode_ptr = new_ent^ode_ptr; 
first jode = FALSE; 

} 

else 

{ 

ent jode_ptr->en^ext_ent = new_ent^ode_ptr; 
ent^ode_ptr = new_ent^ode_ptr; 

} 

ent_count— ; 

} 

first^en_sub = TRUE; 
readstr(dap ^d,temp_str); 

db_ptr->edn jum^en = str_to jum(temp^tr); 
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gen_sub_count = db_ptr->edn_num_gen; 
while ( gen_sub_count != 0 ) 

{ 

/* the gen subtype nodes are allocated and filled here */ 
new_gen_j>tr = rd_gen_sub_node(dap_fid); 
if ( first_gen_sub == TRUE ) 

{ . 

/* special case of first generalization node */ 
db_ptr->edn_subptr = new_gen_ptr; 
genjptr = new_gen_ptr; 
first_gen_sub — FALSE; 

} 

else 

{ 

genjptr->gsn jiext_genptr = new_genjptr; 
genjptr = new_gen jptr; 

} 

gen_sub_count— ; 

} 

/* Process the overlap nodes */ 

gen_ptr = db_ptr -> edn_subptr; 
while (gen_ptr != NULL) 

{ /* begin while gen_ptr <> NULL */ 
first_super = TRUE; 
readstr(dap^d,temp_str); 

genjptr->gsn _num_ent = str_to_num(temp_str); 
super_count = gen_ptr->gsn_num _ent; 
while ( super_count != 0 ) 

{ 

/* the subtypes with one or more entity supertypes */ 

/* nodes axe allocated and filled here */ 

new_overlapent_ptr = rd_overlap_ent_node(dap_fid, 

db_ptr->edn_entity); 

if ( first_super == TRUE ) 

{ 

/* the special case of the first overlap ent node */ 
genjptr- >gsn_entptr = new_overlapent jptr; 
overlapent_ptr = new_overlapent_ptr; 
first_super = FALSE; 

} 

else 

{ 

overlapentjptr->oen^ext^ame = new_overlapent_ptr; 
overlapent_ptr = new _overlapent jptr; 

} 

— super_count; 

} /* end super type node */ 

first _sub_super = TRUE; 
readstr(dap_fid,temp_str); 

gen_ptr->gsn_num_sub = str_to_num(temp_str); 
sub_super_count = gen_j>tr->gsn_num_sub; 
while ( sub_super_count != 0 ) 

{ 
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/* the subtype supertypes are allocated here */ 
new_overlapsub_ptr = rd_overlap_sub_node(dap_fid, 

db_ptr->edn_subptr); 
if ( first_sub_super == TRUE ) 

{ 

/* special case of first overlapsub node */ 
gen_ptr->gsn_subptr = new_overlapsub_ptr; 
overlapsub_ptr = new_overlapsub_ptr; 
first_sub_super = FALSE; 

} 

else 

{ 

overlapsub_ptr->osn ^ext jame = new_overlapsub_ptr; 
overlapsub_ptr = new_overlapsub_ptr; 

} 

— sub_super_count; 

} /* end overlapsub loop */ 

gen_ptr = gen_ptr -> gsn __next_genptr; 

} 

/* Process the sub non nodes */ 
readstr(dap _fid,temp_str); 

db_ptr->edn jum_nonsub = str_to _num(temp_str); 
first_jion_sub — TRUE; 

non_sub_count = db_ptr->edn jum jonsub; 
while ( non_sub_count != 0 ) 

{ 

/* the nonentity subtype nodes are allocated and filled */ 
new_subnon_ptr = rd_sub _non^ode(dap_fid); 
if ( first^on_sub == TRUE ) 

{ 

/* special case of first nonentity subtype node */ 
db_ptr->edn_jionsubptr = new_subnon_ptr; 
subnon_ptr = new_subnon_ptr; 
first_jion_sub = FALSE; 

} 

else 

{ 

subnon_ptr->snn jext_jiode = new_subnon_ptr; 
subnon_ptr = new _subnon_ptr; 

} 

first_value = TRUE; 

num_yal = subnon_ptr->snn _jium_values; 
while ( num_val != 0 ) 

{ 

/* the value nodes are allocated and filled here * / 
new _entval_ptr = rd_ent_yalue(dap_fid, 

subnon_ptr->snn_totaMength); 
if ( first_value == TRUE ) 

{ 

/* special case of first actual value */ 
subnon_ptr->snn_yalue = new_entval_ptr; 
entval_ptr = new_entval_ptr; 
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first_value = FALSE; 

} 

else 

{ 

entval_ptr->ev jext_yalue = new_entval_ptr; 
entval_ptr = new_entval_ptr; 

} 

— num_val; 

} /* end actual value loop */ 

— non_sub_count; 

} /* end subtype nonentity loop * / 



/* Process the derived nodes * / 
readstr(dap^d,temp_str); 

db_ptr->edn_num_der = str_to_num(temp_str); 
first^on_der = TRUE; 
non_der_count = db_ptr->edn jum_der; 
while ( non_der_count != 0 ) 

{ 

/* the nonentity derived types are allocated and filled here * / 
new_dernon_ptr = rd_der^on^ode(dap ^d); 
if ( first jn on _der == TRUE ) 

{ 

/* special case of first derived type nonentity node * / 
db_ptr->edn^onderptr = new_dernon_ptr; 
dernonjtr = new_dernon_ptr; 
first^on_der = FALSE; 

} 

else 

{ 

dernon_ptr->dnnjext^ode = new_dernon_ptr; 
demon _ptr = new_dernon_ptr; 

} 



first_value = TRUE; 

num^yal = dernon_ptr->dnn ^um_yalues; 
while ( num_val != 0 ) 

{ 

/* the value nodes are allocated and filled here */ 
new_entval_ptr = rd_ent_yalue(dap^d, 

dernon_ptr->dnn_total_length); 
if ( first_value == TRUE ) 

{ 

/* special case of first actual value */ 
dernon_j)tr->dnn_yalue = new _entval_ptr; 
entval_ptr = new_entval_ptr; 
first_value = FALSE; 

} 

else 

{ 

entval_ptr->ev_next_yalue = new jentval_ptr; 
entval_ptr = new_entval_ptr; 

} 
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— num_yal; 

} /* end actual value loop * j 
— non_der_count; 

} /* end derived type non entity loop */ 

j* NOW PROCESS THE FUNCTION NODES */ 

/* First, for entity nodes */ 

ent ^ode_ptr — db_ptr->edn_entity; 
while ( ent_node_ptr != NULL ) 

{ 

first_func = TRUE; 

funct_count = ent _node_ptr->en_num_funct; 
while ( funct_count != 0 ) 

{ 

/* function type nodes are allocated and filled here * / 
new_func_ptr = rd_function ^ode(dap^id,db_ptr); 
if ( first_func == TRUE ) 

{ 

/* the special case of first function node */ 
ent_node_ptr->en_ftnptr = new_func_ptr; 
func_ptr = new_func_ptr; 
first_func = FALSE; 

} 

else 

{ 

func_ptr->fn_next^ntptr = new^unc_ptr; 
func_ptr = new_func_ptr; 

} 

— funct_count; 

} /* end function loop * / 
ent^ode_ptr = ent^ode_ptr->en^ext_ent; 

} /* end while loop for ent function nodes */ 

/* Now Process the gen sub node function nodes * / 

gen_ptr = db_ptr->edn_subptr; 
while ( gen_ptr != NULL ) 

{ 

first^unc — TRUE; 

funct_count = gen_ptr->gsn^um_funct; 
while ( funct_count != 0 ) 

{ 

/* the function type nodes are allocated and filled here * / 
new_func_ptr = rd_function_node(dap _fid,db_ptr); 
if ( first^func == TRUE ) 

{ 

/* the special case of the first function node */ 
gen_ptr->gsn Jtnptr = new_func_ptr; 
func_ptr = new_func_ptr; 
first_func = FALSE; 

} 

else 

{ 
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func_ptr->fn _next^ntptr = new_func_ptr; 
func_ptr = new_func _ptr; 

} 

funct^count— ; 

} /* end function loop */ 
gen_ptr = gen_ptr->gsn ^ext_genptr; 

} /* end while loop for gen sub function nodes */ 

} /* end if done Jlag != TRUE loop */ 

} /* end shema makelist loop */ 

T^iflef EnExFlag 

printf ("Exit2 creat_dap_db^ist”); 

#endif 

} /* End creat_dap_dbj_ist */ 

static struct ent_dbid _node *rd_ent_dbid _node ( fid, flag ) 

FILE *fid; 
int *flag; 



{ 

struct ent_dbid _node *db_ptr, /* pointer to database node * / 

* ent_dbid _jiode _alloc( ); /* pointer to newly * / 

/* allocated database node */ 

char temp_str [NUMDIGIT -f l]; /* temp string to hold file ID * / 

#iflef EnExFlag 

printf(”Enter rd_ent_dbid _node"); 

#endif 

/* this function allocates a new database node and returns a pointer */ 
/* to it V 

/* a new database node is established and ptrs are initialized * / 

db_ptr = ent_dbid _node _alloc( ); 
db_ptr->edn _nonentity = NULL; 
db_ptr->edn_entity = NULL; 
db_ptr->edn_subptr = NULL; 
db_ptr->edn _next_db = NULL; 
db_ptr->edn _nonsubptr = NULL; 
db_ptr->edn _nonderptr = NULL; 

readstr(fid,db_ptr->edn jame); 
if ( db_ptr->edn jame[0] == ) 

{ 

/* when file becomes empty */ 

*flag = TRUE; 

free (db_ptr); 

#iflef EnExFlag 

printf("Exitl ent_dbid _node"); 

#endif 

return(NULL); 

} 

else 
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{ 

readstr(fid,temp_str); 

dbjptr->edn _numjonent = str_to_num(temp^tr)*, 
EnExFIag 

printf(”Exit2 rd_ent_dbid ^ode'^); 

#endif 

return (db_ptr); 

} 

} /* end rd_ent_dbid_node */ 



static struct ent _non _node *rd_ent _non^ode(fid) 

FILE *fid; 

{ 

struct ent^on _node *non_ent_ptr, /* pointer to base type * j 

/* nonentity node */ 

*ent _non_node _alloc(); /* pointer to newly allocated */ 

/* nonentity node * / 

char temp_str[NUMDIGIT -I- l]; /* temp string to read fields */ 



/* this function allocates a new base type nonentity node and */ 
/* returns a pointer to it */ 

^iflef EnExFIag 

printf ("Enter rd_ent^on ^ode”); 

#endif 

/* get new base type nonentity node and initialize pointers */ 

non_ent_ptr = ent_non^ode _alloc( ); 
non_ent_ptr->enn_yalue = NULL; 
non_ent_ptr->enn^ext _node = NULL; 

/* now the node is filled in by reading the file * / 

readstr(fid,non_ent_ptr->enn^ame); 
readstr(fid,temp_str); 
non_ent_ptr->enn_type = temp_str[0]; 
readstr(fidjtemp^tr); 

non_ent_ptr->enn_totaMength = str_to^um(temp_str); 
readstr(fidjtemp^tr); 

non_ent_ptr->enn_range = str_to^um(temp_str); 
readstr(fid,temp_str); 

non_ent_ptr->enn_constant = str_to _num(temp_str); 
readstr(fid,temp_str); 

non_ent_ptr->enn jum_values = str_to^um(temp_str); 

^iflef EnExFIag 

printf("Exit rd_ent _non^ode"); 

#endif 

return(non_ent_ptr); 

} I* end rd_ent _non^ode */ 
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static struct ent^value *rd_ent_value(fid, length) 

FILE *fid; 
int length; 

{ 

struct ent_yalue *entval_ptr, /* pointer to def for value */ 
*ent_value _alloc( ); /* pointer fo newly allocated */ 
j* value node * / 

char temp _str[NUMDIGIT l]; /* temp string to read fields * / 

char *var_str _alloc(); 

/* this function allocates a new value node and returns a pointer * / 
/* to it 7 

#ifief EnExFlag 

printf( "Enter rd_ent_yalue^ode"); 

^endif 

/* get the new value node and initialize ptrs * / 

entval_ptr = ent_value _alloc( ); 
entval_ptr->ev_next_yalue = NULL; 

/* now value node is filled in by reading the file */ 

entval_ptr->ev_yalue = var^tr _alloc (length -j- 1); 
readstr(fid,entval_ptr->ev_yalue); 

T^iflef EnExFlag 

printf("Exit rd_ent_yalue jode"); 

#endif 

return (entval_ptr); 

} /* end rd_ent_value */ 



static struct ent^ode *rd_ent_node(fid) 

FILE *fid; 

{ 

struct ent_node *ent jode_ptr, /* pointer to entity node */ 

*ent jode _alloc( ); /* pointer to newly allocated * / 

/* entity node */ 

char temp_str[NUMDIGIT -{- l]; 

/* this function allocates a new entity node and returns a pointer * / 
/* to it 7 

#iflef EnExFlag 

printf("Enter rd_ent_node"); 

#endif 

/* get new entity node and initialize values */ 
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ent _node_ptr = ent ^ode _alloc{ ); 
ent _node jtr->en Jtnptr = NULL; 
ent _node_ptr->en_next_ent = NULL; 

/* now the entity node is filled in by reading the file */ 

readstr(fid,ent ^ode_ptr->en _name); 
readstr(fid,temp_str); 

ent _node_ptr->en_num^unct = str_to^um(temp_str); 
readstr(fid,t€mp^tr); 

ent _node_ptr->en_terminal = str_to _num{temp_str); 

^ifief EnExFlag 

printf('*Exit rd_ent_node”); 

^endif 

return(ent _node_ptr); 

} /* end rd_ent _node */ 



static struct function_node *rd_function^ode(fid, dbjtr) 

FILE *fid; 

struct ent_dbid_node *db_ptr; 

{ 

struct function jode *func_ptr, /* pointer to function type node */ 
*function^ode _alloc( ); /* pointer to newly allocated */ 
/* function type node */ 

char temp_str[NUMDIGIT + l]; 
char name_str[ENLength -h l]; 
int num_yal, 
first_value; 

struct ent_yalue *entval_ptr, 

*new_entval_ptr, 

*rd_ent_value{); 
struct ent _node *ent_ptr; 
struct gen_sub _node *sub_ptr; 
struct ent _non ^ode *enon_ptr; 
struct sub _non _node *non_ptr; 
struct der _non^ode *der_ptr; 
int done _flag; 

/* this function allocates a new function node and returns a pointer */ 
/* to it V 

#iflef EnExFlag 

printf('*Enter rd^unction jiode"); 

#endif 

/* get new function node and initialize values */ 

func_ptr = function^ode _alloc( ); 
func_ptr->fn_value = NULL; 
func_ptr->fn_entptr = NULL; 
func_ptr->fn_subptr = NULL; 
func_ptr->fn _nonentptr = NULL; 
func_ptr->fn _nonsubptr = NULL; 
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func_ptr->fn jonderptr = NULL; 
func_ptr->fn^ext Jntptr = NULL; 

/* now the function node is filled in by reading the file */ 

readstr(fid,func_ptr->fn^ame); 
readstr(rid,temp_str); 
func_ptr->fn_type = temp_str[0]; 
readstr(fid,temp_str); 

func_ptr->fn_range = str_to_num(temp_str); 
readstr(fid,temp_str); 

func_ptr->fn_totaMength = str_to^um(temp_str); 
readstr(fid,temp_str); 

func_ptr->fn^um_yalue = str_to^um(temp^tr); 

riTst_yalue = TRUE; 

num_yal = func_ptr->fn_num_yalue; 

while ( num_yal != 0 ) 

{ 

/* value nodes are allocated and filled here */ 
new_entval_ptr = rd_ent_yalue(fid, 

func_ptr->fn_totaMength); 
if ( first_yalue == TRUE ) 

{ 

/* special case of first value */ 
func _ptr->fn_yalue = new_entval_ptr; 
entval_ptr = new _entval_ptr; 
first_yalue = FALSE; 

} 

else 

{ 

entval_ptr->ev^ext_value = new_entval_ptr; 
entval_ptr = newjentval_ptr; 

} 

— num_val; 

} /* end value loop */ 

readstr(fid, name_str); 
if (name_str[0] != 

{ 

done^ag = FALSE; 
ent_ptr = db_ptr->edn _entity; 
while (done^ag == FALSE) 
if (strcmp(name_str, ent j>tr->en^ame) == 0) 

{ 

done^ag = TRUE; 
func_ptr->fn_entptr = ent_ptr; 

} 

else 

{ 

ent_ptr = ent_ptr->en_next_ent; 
if (ent_ptr == NULL) donejlag = TRUE; 

} 

} 

readstr(fid, name_str); 



78 



if (name^tr[0] != 

{ 

done_flag = FALSE; 
sub_ptr = db_ptr->edn_subptr; 
while (done^ag == FALSE) 
if (strcmp(name_str, sub_ptr->gsn_name) == 0) 

{ 

done^ag = TRUE; 
func_ptr->fn_subptr = sub_ptr; 

} 

else 

{ 

sub_ptr = sub_ptr->gsn_next_genptr; 
if (sub_ptr == NULL) donejlag = TRUE; 

} 

} 

readstr(fid, name_str); 
if (name_str[0] != 

{ 

done^ag = FALSE; 
enon_ptr = db_ptr->edn_nonentity; 
while (done^ag == FALSE) 
if (strcmp(name_str, enon_ptr->enn^ame) == 0) 
{ 

done_flag = TRUE; 
funcjptr->fn_nonentptr = enonjtr; 

} 

else 

{ 

enon_ptr = enon_ptr->enn_next^ode; 
if (enon_ptr == NULL) done^ag = TRUE; 

} 

} 

readstr(fid, name^tr); 
if (name_str[0] != ’"’) 

{ 

done_flag = FALSE; 
nonjptr = db_ptr->edn jonsubptr; 
while (done^ag == FALSE) 
if (strcmp(name_str, non_ptr->snn_name) == 0) 

{ . 

done_flag = TRUE; 
func_ptr->fn^onsubptr = non_ptr; 

} 

else 

{ 

non_ptr = non_ptr->snn _next jode; 
if (non_ptr == NULL) done_nag = TRUE; 

} 

} 

readstr(fid, name_str); 
if (name_str[0] != ^"’) 

{ 
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done _flag = FALSE; 
der_ptr = db_ptr->edn^onderptr; 
while (done^ag == FALSE) 
if (strcmp(name_str, der_ptr->dnn jame) == 0) 

{ 

done _flag = TRUE; 
func_ptr->fn jonderptr = der_ptr; 

} 

else 

{ 

derjtr = der_ptr->dnn jiext_node; 
if (der_ptr == NULL) done _flag = TRUE; 

} 

} 

readstr(fid,temp^tr); 

func_ptr->fn_entnull = str_to ^um(temp_str); 
readstr(fid,teinp_str); 

func_ptr->fn_unique — strJto^um(temp_str); 

#iflef EnExFlag 

printf("Exit rd^unction node"); 

^endif 

return (func_ptr); 

} /* end rd^unction^ode * / 

static struct gen_sub^ode *rd_gen_sub^ode(fid) 

FILE *fid; 

struct gen_sub_node *gen_ptr, /* pointer to generalization node */ 
*gen_subjode _alloc( ); /* pointer to newly allocated */ 

/* generalization node */ 

chaj temp_str[NUMDIGIT -h l]; 

/* this function allocates a new generalization node and returns a */ 
/* pointer to it */ 

#iflef EnExFlag 

printf("Enter rd_gen_sub^ode"); 

#endif 

/* get new generalization node and initialize ptrs */ 

gen_ptr = gen _sub_node _alloc( ); 
gen_ptr->gsn_entptr = NULL; 
gen_ptr->gsn_ftnptr = NULL; 
gen_ptr->gsn_subptr = NULL; 
gen_ptr->gsn^ext_genptr = NULL; 

/* now the generalization node is filled in by reading the file */ 

readstr(fid,gen_ptr->gsn^ame); 

readstr(fid,temp^tr); 

gen_ptr->gsn^umj^unct = str_to^um(temp^tr); 
readstr(fid,temp_str); 
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gen_ptr->gsn_terminal = str_to_num(temp_str); 

^iflef EnExFlag 

printf("Exit rd_gen_sub jode"); 

^endif 

return (gen_ptr); 

} /* end rd_gen _sub_node */ 



static struct overlap_ent jode *rd_overlap_ent^ode(fid, ent_ptr) 

FILE *fid; 

struct ent jode *ent_ptr; 

{ 

struct overlap_ent^ode *overlap_ptr, /* pointer to node */ 
*overlap_ent ^ode _alloc( ); /* pointer to newly */ 

/* allocated node */ 

char temp_str[NUMDIGIT + l]; 
char name_str[ENLength + l]; 
int done^ag; 

/* this function allocates a new subtype with one or more entity node */ 
/* and returns a pointer to it */ 

^iflef EnExFlag 

printf("Enter rd_overlap_ent _node"); 

#endif 

/* get new node and initialize pointers */ 

overlap_ptr = overlap_ent jode _alloc( ); 
readstr(fid, name _str); 

done _flag = FALSE; 
while (done^ag == FALSE) 

if (strcmp(name _str, ent_ptr->en jame) == 0) 

{ 

overlap_ptr->oen^ame = ent_ptr; 
done _flag = TRUE; 

} 

else 

{ 

ent_ptr = ent_ptr->en^ext_ent; 
if (ent_ptr == NULL) done^ag = TRUE; 

} 

overlap_ptr->oen_next^ame = NULL; 

#iflef EnExFlag 

printf("Exit rd_overlap_ent jode"); 

#endif 

return(overlap_ptr) ; 

} /* end overlap_ent^ode */ 
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static struct overlap_sub_node *rd_overlap_sub _node(fid,gen^tr) 

FILE *fid; 

struct gen^sub _node *gen_ptr; 

{ 

struct overlap^sub _node *overlapsubjptr, /* pointer to termimal */ 

/* subtype nodes */ 

*overlap_sub _node _alloc(); /* pointer to newly * j 

/* allocated node */ 

char temp_str[NUMDIGIT 4- l]; 
char name _str[ENLength + ij; 
int donejag; 

/* this function allocates a new terminal subtype node and returns a * / 
/* pointer to it * / 

#iflef EnExFlag 

printf("Enter rd_overlapsub _node”); 

#endif 

/* get new terminal subtype node and initialize pointers */ 

overlapsub_ptr = overlap_sub _node _alloc(); 
readstr(fid, name_str); 

donejlag = FALSE; 
while (done^ag — — FALSE) 

if (strcmp(name_str, gen_ptr->gsn _name) == 0) 

{ 

overlapsub_ptr->osn _name = gen_ptr; 

done^ag = TRUE; 

} 

else 

{ 

gen_ptr = gen_ptr->gsn jextjgenptr; 
if (gen_ptr == NULL) done^ag = TRUE; 

} 

overlapsub_ptr->osn _next _name = NULL; 

#iflef EnExFlag 

printf(”Exit rd_overlapsub _node**); 

#endif 

return(overlapsub_ptr); 

} /* end rd_overlapsub _node */ 

static struct sub jon _node *rd^ub _non ^ode(fid) 

FILE *fid; 

{ 

struct sub _non ^ode *subnon_ptr, /* pointer to subtype nonentity */ 

/* node V 

*sub _non _node _alloc( ); j* pointer to newly allocated */ 

/* nonentity node */ 

char temp_str[NUMDIGIT + l]; 
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/* this function allocates a new subtype nonentity node and returns a */ 
/* pointer to it */ 



^iflef EnExFlag 

printf( "Enter rd_sub _non _node"); 

# end if 

/* get new subtype nonentity node and initialize pointers */ 

subnon_ptr = sub _non _node _alloc( ); 
subnon_ptr->snn_yalue = NULL; 
subnon_ptr->snn _next _node = NULL; 

/* now the subtype nonentity node is filled in by reading the file * / 

readstr(fid,subnonjptr->snn jame); 
readstr (fid, tern p^tr) ; 
subnon_ptr->snn_type = temp_str[0]; 
readstr(fid,temp_str); 

subnon_ptr->snn_totaMength = str_to _num(temp_str); 
readstr(fid,temp^tr); 

subnon_ptr->snn^ange = str_to _num(temp_str); 
readstr(fid,temp_str) ; 

subnon _ptr->snn ^um_values = str_to _num(temp_str); 

^iSef EnExFlag 

printf("Exit rd_sub ^on _node"); 

#endif 

return(subnon_ptr) ; 

} /* end rd_sub ^on _node * / 

static struct der ^on _node *rd_der ^on ^ode(fid) 

FILE *fid; 

{ 

struct der _non _node *dernon_ptr, /* pointer to derived type * / 

/* nonentity node 

"^der _non _node _alloc( ); /* pointer to newly allocated * / 

/* derived type */ 

char temp_str[NUMDIGIT + l]; 

/* this function allocates a new derived type nonentity node and returns */ 
/* a pointer to it 

T^iflef EnExFlag 

printf("Enter rd_der _non _node"); 

#endif 

/* get new derived type nonentity node and initialize pointers / 

dernonjptr = der _non _node _alloc( ); 
dernon_ptr->dnn_value = NULL; 
dernonjptr- >dnn ^ext _node = NULL; 

/* now the derived type nonentity node is filled * / 
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readstr(fid,dernon_ptr->dnn^ame); 
readstr(fid , tern p_str) ; 
demon _ptr->dnn_type = temp_str[0); 
readstr(fid,temp_str); 

dernon_ptr->dnn_total_length = str_to jum(temp_str); 
readstr(fid,temp_str); 

demon _ptr->dnn^ange = str_to jum(temp_str); 
readstr(fid,temp_str); 

dernon_ptr->dnn^um_values = str_to_num(temp_str); 

^iflef EnExFlag 

printf("Exit rd_der jon^ode"); 

#endif 

return (dernon_ptr) ; 

} /* end rd_dernon jode */ 
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APPENDIX C 



THE LIL MODULE 



^include <stdio.h> 

^include "licommdata.deP 
^include "struct.deP* 

^include "flags. deP^ 

^include "dap. ext" 

^include "lil.dcl" 

language_interface^ayer( ) 

/* This proc allows the user to interface with the system. */ 

/* Input and output: user DAPLEX requests * j 

{ 

int num; 

int stop; /* boolean flag */ 

#fdef EnExFlag 

printf ("Enter language^nterface^ayerO); ^ndif 
dap_init(); 

/* initialize several ptrs to different parts of the user structure */ 

/* for ease of access */ 

dap_info_ptr = &(cuser_dapjptr->uMi_type.li_dap); 

tran_info_ptr = &:(dap_info_ptr->dpi _dmljbran); 

flrst^eq_ptr = &(tran^nfo_ptr->tiJ^st^eq); 

curr^eq_ptr = &(tran^nfo_ptr->ti_curr^eq); 

stop = FALSE; 

while (stop == FALSE) 

{ 

/* allow user choice of several processing operations */ 
printf ("Onter type of operation desiredO); 
printf ("(1) - load new databaseO); 
printf ("(p) - process existing databaseO); 
printf ("(x) - return to the operating systemO); 
dap^nfo_ptr->dap_answer = get _ans(&num); 

switch (dap^nfo_ptr->dap janswer) 
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{ 



case ’1’: /* user desires to load a new database */ 
load^ew(); 
break; 

case ’p’: /* user desires to process an existing database */ 
process_old(); 
break; 

case ’x’: /* user desires to exit to the operating system */ 

/* database list must be saved back to a file */ 

stop = TRUE; 

break; 

default: /* user did not select a valid choice from the menu */ 
printf (”0rror - invalid operation selectedO); 
printf (’^Please pick againO); 
break; 

} /* end switch */ 

/* return to main menu */ 

} /* end while */ 

#fdef EnExFlag 

printf ("Exit language^nterface^ayerO); =^ndif 
} /* end language^nterface_layer */ 
dap_init() { 

^fdef EnExFlag 

printf ("Enter dap^nitO); ^endif 

#fdef EnExFlag 

printf ("Exit dap^nitO); ^ndif 

} /* end dap^nit */ 

load^ew() 

/* This proc accomplishes the following: */ 

/* (1) determines if the new database name already exists, . */ 
/* (2) adds a new header node to the list of schemas, */ 

/* (3) determines the user input mode (file/terminal), */ 

/* (4) reads the user input and forwards it to the parser, and */ 
/* (5) calls the routine that builds the template/descriptor files */ 
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{ 

int num; 

int stop; /* boolean flag */ 

int more^nput; /* boolean flag */ 
int proceed; /* boolean flag */ 

struct entjdbid jiode *db^ist_ptr, /* ptr to the current db */ 

*new_ptr, /* ptr to a new db structure */ 

*ent_dbid^ode _alloc(); /* ptr to allocated db */ 

#fdef EnExFlag 

printf (’’Enter load^ewO); ^ndif 

/* prompt user for name of new database */ 

printf (”[7;7m0nter name of database — >[0;0m ”); 

readstr (stdin, dap^nfo_ptr->dpi_curr _db.cdi_dbname); 

to_caps (dap^nfo_ptr->dpi_curr_db.cdi_dbname); 

dbj^ist_ptr = dbs_dap ^ead_j)tr.dn_dap; 

stop = FALSE; 

while (stop == FALSE) 

{ 

/* determine if new database name already exists */ 

/* by traversing list of entity-relation db schemas ^ / 
if ((strcmp(dbj^ist_ptr->edn ^ame, 

dap^nfo_ptr->dpi_curr_db.cdi_dbname))== 0) 

{ 

printf (’’Orror - db name already existsO); 

printf (”[7;7mPlease reenter db name — >[0;0m ”); 

readstr (stdin, dap^nfo_ptr->dpi_curr_db.cdi_dbname); to_caps (dap^nfo_ptr- 

>dpi_curr_db.cdi_dbname); 

db^ist_ptr = dbs_dap ^ead_ptr.dn_dap; 

} /* end if V 

else /* check for last database of the list */ if (db^ist_ptr->edn _next_db == 

NULL) stop = TRUE; else 

/* increment to next database */ 
db^ist_ptr = db^ist_ptr->edn^ext_db; 

} /* end while */ 

/* continue - user input a valid ’new’ database name */ 

/* add new header node to the list of schemas and fill-in db name */ 

/* append new header node to db^ist & init relevent user stucture ptrs */ 
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new_ptr = ent_dbid^ode _alloc(); 

strcpy (new_ptr->edn_name, dap_info_ptr->dpi_curr_db.cdi_dbname); 
/* new_ptr->dpidn_nuin_set = 0; */ 

/* new_ptr->dpidn ^um^rec = 0; */ 

/* new_ptr->dpidn^rst_set = NULL; */ 

/* new_ptr->dpidn ^u*st_rec = NULL; */ 

/* new_ptr->dpidn^ext_db = NULL; */ 
db^ist_ptr->edn^ext _db = new_ptr; 
dap_info_ptr->dpijcurr_db.cdi_db.dn_dap = new_ptr; 
dap_info_ptr->dpi_curr_db.cdi _attr.an_dattr_ptr = NULL; 

/* check for user’s mode of input */ 

more_input = TRUE; 

while (more^nput == TRUE) 

{ 

/* determine user’s mode of input */ 

printf ("Onter mode of input desiredO); 

printf ("(f) - read in database description from a fileO); 

printf ("(x) - return to the to main menuO); 

dap_i^nfo_ptr->dap _answer = get _ans(&num); 



switch (dap_mfo_ptr->dap _answer) 

{ 



case ’f: /* user input is from a file */ 

read_transaction _file(); if (dap_info_ptr->dap_error 

{ /* file contains transactions */ / 

database description */ dbd_to^MS(); 

if (dap_info_ptr->dap_error != ErrCreateDB) 

/* no syntax errors in creates */ 

build_ddl^les(); 

Kernel_Controller(); } /* end if */ 

break; 

case ’x’: /* exit back to LIL */ 
more_input = FALSE; 
break; 

default: /* user did not select a valid choice from the menu */ 
printf ("Orror - invalid input mode selectedO); 
printf ("Please pick againO); 
break; 



!= ErrReadFile) 
* dbd stands for 
free^equests(); 

{ 



} /* end if V 
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} /* end switch */ 

if (dap_info_ptr->dap_error == ErrCreateDB) /* errors in creates so exit this loop */ 

more_input = FALSE; 

dap^nfo j)tr->dap_error = NOErr; 

} /* end while */ 

#fdef EnExFlag 

printf ("Exit load_newO); ^endif 
} /* end load^ew */ 
process_old() 

/* This proc accomplishes the following: */ 

/* (1) determines if the database name already exists, */ 

/* (2) determines the user input mode (file/terminal), */ 

/* (3) reads the user input and forwards it to the parser */ 

{ 

int found, more_input; /* boolean flags */ 

int num; 

struct ent_dbid jiode *db_list_ptr; /* ptr to the current database */ 

#fdef EnExFlag 

printf ("Enter process_oldO); ^ndif 

/* prompt user for name of existing database */ 

printf ("[7;7m0nter name of database >[0;0m "); 

readstr (stdln, dap_info_ptr->dpi_curr_db.cdi_dbname); 
to_caps (dap^nfo_ptr->dpi_curr_db.cdi _dbname); 
db_list_ptr = dbs_dap ^ead_ptr.dn_dap; 

found = FALSE; 
while (found == FALSE) 

{ 

/* determine if database name does exist */ 

/* by traversing list of entity-relation schemas */ 

if (strcmp(dap_info_ptr->dpi_curr_db.cdi_dbname,db^ist_ptr->edn^ame) = = 0) 
found = TRUE; 
else 

{ 
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db_list j)tr = db_[istjptr->edn_next_db; 

/* error condition causes end of list(’NULL^) to be reached */ 
if (db^ist _ptr == NULL) 

{ 

printf ("Orror - db name does not existO); 
printf ("(7;7mPlease reenter valid db name — >[0;0m "); 
readstr (stdin, dap^nfo_ptr->dpi_curr_db.cdi_dbname); 
(dap_ 2 nfojptr->dpi_curr_db.cdi_dbname); 

db_Hst_ptr = dbs_dap _head_ptr.dn_dap; 

} j* end if */ 

} /* end else */ 

} j* end while */ 

/* continue - user input a valid existing database name */ 

/* determine user’s mode of input */ 

more^nput = TRUE; 

while (more^nput == TRUE) 

{ 

printf ("Onter mode of input desiredO); 

printf ("(f) - read in a group of DAPLEX requests from a fileO); 
printf C’(t) - read in DAPLEX requests from the terminalO); 
printf ("(x) - return to the previous menuO); 
dap^nfo_ptr->dap ^nswer = get _ans(&num); 

switch (dap^nfo_ptr->dap _answer) 

{ 

case T: j* user input is from a file */ 

read_transaction_file(); dapreqs_to ^MS(); 

free^equests(); break; 

case ’t’: user input is from the terminal */ 

read_terminal(); 

dapreqs_to ^MS(); free^equests(); break; 

case ’x’: /* user wishes to return to LIL menu */ 
more^nput = FALSE; 
break; 

default: /* user did not select a valid choice from the menu */ 
printf ("Orror - invalid input mode selectedO); 
printf ("Please pick againO); break; 



to_caps 
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} /* end switch */ 

} /* end while */ 

#fdef EnExFlag 

printf (^^Exit process _oldO); #endif 
} /* end process _old */ 
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APPENDIX D 



THE KMS MODULE 



/* Last Date Modified: 12 Nov 85 / ja / building db description ops */ 



{ 



^include <stdio.h> 
^include "licommdata.def* 
^include ”struct.deP 
^include ’’dap.ext’^ 
^include ’’flags.def 



int creating = FALSE; int serror; int in; int ini; int in2; int in3; int in4; int inS; int add; 
int present; int there; int i, j; int move, nmove; int b; int nsub,esub; int curr_op; int 
check^ds; int dummy, dummy2; int ada _expression; 

char temp_str[NUMDIGIT -h l]*, char db[DBNlength + l]; char temp_value[ENlength + l]; char 
temp[ENlength -f- l]; char type jame^d[ENlength + l]; 

struct ent_dbid^ode *db_ptr; struct ent^on^ode *non _ent_ptrl, 

*non _entjptr2; struct ent_yalue *entvaljptrl, 

*entval_ptr2; struct subjon^ode *subnon_ptrl, 

*subnon_ptr2; struct derjon^ode *dernon_ptrl, 

*dernon_ptr2; struct ent ^ode *ent_ptrl, 

*ent_ptr2; 

*new _entjptr; struct gen_sub^ode *gen_ptrl, 

*gen _ptr2; 

*new^en_ptr; struct overlap _ent jode *overlapent_ptrl, 

*overlapent _ptr2; struct overlap^ub _node *overlapsub_ptrl, 

*overlapsub_ptr2; struct function ^ode *func_ptrl, 

*func_ptr2; struct dap ^ms^nfo *kms_ptr; struct dapjcms^nfo 

*dap_kms^nfo _alloc(); struct ident^ist *id_ptr, 

*temp_ptr, 

*new_temp_ptr, 

*new_id_ptr; struct ent_non_node *dap _ent ^on_node _alloc(); struct 

ent jode *dap _ent jode _alloc(); struct function jode *dap^unc jode _alloc(); struct 

sub^on^ode *dap^ub^on jode _alloc(); struct der ^onjnode 
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'*‘dap_der ^onjode _alloc(); struct ent_yalue *dap_ent_yalue _alloc(); struct dap_create_l_ist 

*create^istl, 

*create_list2, 

*dap_create^ist _alloc(); 

%union 

{ 

char str[20]; 

} 

%token DATABASE %token ENTITY %token OVERLAP %token TEMPORARY %token 
TRUE %token FALSE %token END %token IS %token WITH %token WITHIN %token 
UNIQUE %token TYPE %token SUBTYPE %token NEW %token EMPTY %token 
CREATE %token CONSTANT %token AND %token OR %token XOR %token THEN 
%token ELSE %token FOR %token EACH /?token DELTA %token NULL %token WITH- 
NULL %token WITHOUTNULL %token SET %token IMAGE %token POS %token VALUE 
%token VAL 

%token <str> IDENTIFIER %token <str> NUMERIC _LITERAL %token <str> STRING 
%token <str> CHARACTER_STRING %token <str> LITERAL_STRING %token <str> 
FLOAT %token <str> INTEGER /?token <str> BOOLEAN %token <str> RANGE 
%token <str> DIGITS %token <str> ELIPSES %token <str> COLON %token <str> 
SEMICOLON %token <str> DOT %token <str> COMMA %token <str> ASSIGN %token 
<str> LP %token <str> RP %token <str> HYPHEN %token <str> IMPLY 

%token <str> subtype_indicator %token <str> subtype indication 
%start statement 
%% 

statement: ddl_statement 

{ 

YYACCEPT; 

} 



ddl_statement: database_specification 
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{ 

proc^ree_^d_list ( ) ; 

} 

database _specification: TEMPORARY database definition 
I database_definition 
) 

database_definition: DATABASE 
{ #iHef HYacFlag 

printf("Database in database definition recognizedO); ^ndif 
check^ds = TRUE; 
creating = TRUE; 

} 

visible_part end_database 

j 

end_database: end^nodule 

j 

end jnodule: END 
I END 
{ 

check^ds = FALSE; 

} 

name^d 

{ 

db_ptr = cuser_dap_ptr->ui^i_type.li_dap.dpi_curr_db.cdi_db.dn_dap 
strcpy(db,db_ptr->edn _name); 

if(strcmp(temp_yalue, db_ptr->edn _name) != FALSE) 

{ 

serror = 0; 

proc_eval_error(serror) ; 

YYACCEPT; 

} 

} 

visible_part: name^d /* =’s [A-Z][A-Z] in LEX */ 
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/* the ent_dbid jode is located and compared for correctness */ 

{ 

db_ptr = cuser_dap_ptr->ui_[i_type.li_dap.dpi_curr_db.cdi_db.dn_dap; 
strcpy(db,db_ptr->edn^ame); 

if (strcmp(db_ptr->edn _name, temp_value) != FALSE) 

{ 

serror = 0; 

proc_eval_error(serror); 

YYACCEPT; 

} 

} 

IS declarative item list 



declarative^tem^ist: declarative^tem 

I declarative_ 2 tem_list declarative^tem 

j 

declarative_item: declaration 
I consistency_rule 



consistency_rule: overlap_rule 
I uniqueness^ule 

j 

overlap_rule: OVERLAP 

/* the types are checked to insure that they are terminal subtypes */ 

{ 

serror = 14; 
check_ 2 ds = FALSE; 
curr_op = Overlap; 

} 

namel_[ist 

{ 

kms_ptr->dki_overfirst_ptr = kms_ptr->dki_temp_ptr; 
kms_ptr->dki_temp_ptr = NULL; 
ov_ptr = kms_ptr->dki_overfirst_ptr; 
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in = FALSE; 

new_gen_ptr = db_ptr->edn_subptr; 
gen_ptr = new_gen_ptr; 
while (ov_ptr != NULL) 

{ 

while ((gen_ptr != NULL) && (in != TRUE)) 

{ 

if (strcmp(ov_ptr->il jame, gen_ptr->gsn jame) == FALSE) 

{ 

in = TRUE; 

} 

else 

{ 

new_gen_ptr = gen_ptr->gsnjiext_genptr; 
gen_ptr = new_gen_ptr; 

} 

} 

if (in == TRUE) 

{ 

new_ov_ptr = ov_ptr->il jiext; 
ov_ptr = new_ov_ptr; 
new_gen_ptr = db_ptr->edn_subptr; 
gen_ptr = new_gen_ptr; 
in = FALSE; 

} 

else 

{ 

proc_eval_error(serror) ; 

} 

} 

} 

WITH nameljist SEMICOLON 

{ 

in = FALSE; 

new_temp_ptr = kms_ptr->dki_tennp_ptr; 
temp_ptr = new_temp_ptr; 
new_gen_ptr = db_ptr->edn_subptr; 
gen_ptr = new_gen_ptr; 
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new_overlapsub_ptr = gen_ptr->gsn_subptr; 
overlapsub^ptr = new_overlapsub_ptr; 
while (temp_ptr != NULL) 

{ 

while ((genjtr != NULL) && (in == FALSE)) 

{ 

if (strcmp(gen_ptr->gsn^ame, temp_ptr->iljame) == FALSE) 

{ 

in = TRUE; 



new_ov_ptr = kms_ptr->dki_overfirst_ptr; 
ov_ptr = new_ov_ptr; 
while (ov_ptr != NULL) 

{ 

if (overlapsub_ptr == NULL) 

{ 

gen_ptr->gsn_subptr = dap_overlap^ub jode _alloc(); 
new_overlapsub_ptr = gen_ptr->gsn_subptr; 
overlapsub_ptr = new_overlapsub_ptr; 
ov_ptr->il^ame = overlapsub_ptr; 
overlapsub_ptr->osn ^ame = ov_ptr->il^ame; 
overlapsub_ptr->oen jext^ame = NULL; 

} 



else 

{ 

while (overlapsub_j)tr->oen jame != NULL) 
overlapsub_ptr = overlapsub_ptr->oen^ext^ame; 
overlapsub_ptr->oen jext^ame = dap_overlap_sub^ode _alloc() 
new_overlapsub_ptr = overlapsub_j)tr->oen _next^ame; 
overlapsub_ptr = new_overlapsub_ptr; 
ov_ptr->iljiame = overlapsubjtr; 
overlapsub_ptr->osn jiame = ov_ptr->iljiame; 
overlapsub_ptr->oen jext^ame = NULL; 

} 

new_ov_ptr = ov_ptr->il^ext; 
ov_ptr = new_ov_ptr; 

} 



else 
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{ 

new_gen_ptr = gen_ptr->gsn_next_ptr; 
gen_ptr = new_gen_ptr; 

} 

} 

if ((gen_ptr == NULL) && (in == FALSE)) 

{ 

proc_eval_error(serror) ; 

} 

else 

{ 

new_temp_ptr = temp_ptr->il_next; 
temp_ptr = new_temp_ptr; 
new_gen_ptr — db_ptr->edn_subptr; 
gen_ptr = new gen ptr; 
in — — FALSE; 

} 

} 

check_j_ds = TRUE; 

} 

uniqueness^ule: UNIQUE identifier_2ist WITHIN namel SEMICOLON 

{ 

curr_op = Unique; 
check_2ds = FALSE; 

serror = 13; 

/* to create temp^J^ist must be entity type or subtype */ 
in = FALSE; 

new_ent_jiode_ptr — db_ptr->edn_entity; 
ent_node_ptr = new_ent_node_ptr; 
new_gen_ptr = db_ptr->edn_subptr; 
gen_ptr = new_gen_ptr; 
while (ent_node_j)tr != NULL) 

{ 

if (strcmp(ent _node_ptr->en_name, temp_yalue) == FALSE) 

{ 
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/* if the temp_yalue is found in the function */ 

/* node the unique field in the function node */ 

/* is initialized to true, else an error mess- */ 

/* is initiated */ 

in = TRUE; 
there = FALSE; 

new Junc_ptr = ent^ode_ptr->en^tnptr; 
func^ptr = new^unc_ptr; 
new_temp_ptr = kms_ptr->dki_temp_ptr; 
temp_ptr = new_temp_ptr; 
while (temp_ptr != NULL) 

{ 

while (funcjtr != NULL) 

{ 

if(strcmp(temp_ptr->il jame, func_ptr->fn_name) =— FALSE) 

{ 

there = TRUE; 

func_ptr->fn_unique = TRUE; 

} 

else 

{ 

new^unc_ptr = func_ptr->fn^ext_j‘ntptr; 
func_ptr = newjunc_ptr; 

} 

} 

if (there == TRUE) 

{ 

new_temp_ptr = temp_ptr->il^ext; 
temp_ptr = new_temp_ptr; 
new_func_ptr — ent^ode_ptr->en^tnptr; 
func_ptr — new_func_ptr; 
there = FALSE; 

} 

else 

{ 

proc_eval_error(serror) ; 

} 

} 
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} 

else 

{ 

new ent node ptr = ent^ode_ptr->en_next_ent; 
ent ^odejtr = new_ent jode_ptr; 

} 

} 

if (in == FALSE) 

{ 

/* The temp_yalue is compared to each value in the */ 

/* gen_sub_node. If the value is not there, an error * / 

/* message is initiated. */ 

while (gen_ptr != NULL) 

{ 

if (strcmp(gen_ptr->gsn_name, temp_value) == FALSE) 

{ 

in = TRUE; 
there = FALSE; 

newj[unc_ptr = gen_ptr->gsn^tnptr; 
func_ptr = new^unc_ptr; 
new_temp_ptr = kms_ptr->dki_temp_ptr; 
temp_ptr = new_temp_ptr; 
while (temp_ptr != NULL) 

{ 

while (func_ptr != NULL) 

{ 

if(strcmp(temp_ptr->il^ame, func_ptr->fn jiame) == FALSE) 

{ 

there = TRUE; 

func_ptr->fn_unique = TRUE; 

} 

else 

{ 

new_func_ptr = func_ptr->fn jiext_fntptr; 
func_ptr = new_func_ptr; 

} 

} 



100 



if (there == TRUE) 

{ 

new_temp_ptr = temp_ptr->il_next; 
temp_ptr = new_temp_ptr; 
new_func_ptr = genj[iode_ptr->gsn_ftnptr; 
func_ptr = new_func_ptr; 
there = FALSE; 

} 

else 

{ 

proc_eval_error(serror); 

} 

} 

} 

else 

{ 

new_gen_ptr = gen_ptr->gsn_next_genptr; 
gen_j)tr = new_gen_ptr; 

} 

} 

} 

if (in == FALSE) 
proc_e V al_error (serror ) ; 
check^ds = TRUE; 

} 

declaration: number_declaration 
I type ^declaration 
I subtype_declaration 

j 

nu m ber_dec laration : 

{ 

serror = 1; 
check^ds = TRUE; 

} 

identifier Jist COLON CONSTANT ASSIGN simple _const SEMICOLON 

{ 
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temp__ptr = kms_ptr->dki_temp_ptr; 
while (temp_j)tr != NULL) 

{ 

/* At this point ent _non jode’s are filled with the */ 

/* information previously allocated in the kms info */ 

/* structure. The amount of nodes is dependent on */ 

/* the amount of names in the temp structure. */ 

ent ^onjptrl = dap_ent _non ^ode _alloc(); 
strcpy(ent_non_ptrl->enn _jiame, temp_ptr->il ^ame); 
ent _nonjptrl->enn_type = kms_ptr->dki_ent ^on.enn_type ; 
ent _nonjptrl->enn_totaMength = 

kms_ptr->dki_ent _non.enn_totalJength ; 
ent _nonjptrl->enn^ange = kms__ptr->dki_ent _non.enn^ange ; 
ent ^onjptrl->enn ^umj_yalues = 

kms_ptr->dki_ent ^on.enn^um_yalues ; 
ent _jionjptrl->enn_yalue = kms__ptr->dki_ent _non.enn_yalue ; 
kms_ptr->dki_ent _non.enn_yalue = NULL; 
ent _non_ptrl->enn_constant = 

kms_ptr->dki_ent _non.enn_constant ; 
ent _non_ptrl->enn _next _node = NULL; 

ent ^on_ptr2 = db__ptr->edn nonentity; 

if (ent_jion_ptr2 == NULL) 
dbjptr->edn _nonentity = ent _non_ptrl; 
else 
{ 

while (ent jrion_ptr2->enn _next ^ode != NULL) 
ent _non_ptr2 = ent _non_ptr2->enn _next ^ode; 
ent _non_ptr2->enn _next _node = ent ^on_ptrl; 

} 

ent ^on__ptrl = NULL; 
temp_ptr = temp_ptr->il _next; 

} 

check_ids = FALSE; 

} 

j 

simple_const: INTEGER /* dap ^ms^nfo structures are built for subsequent * / 
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/* nonentity node insertion into the schema * / 

{ 

kms _ptr->dki_ent _jion.enn_type = ’i’; 
kms_ptr->dki_ent ^on.enn_totaI_length = INTLength; 
kms_j)tr->dki_ent _non.enn^ange = FALSE; 
kms_ptr->dki_ent^on.enn jium_yalues = 1; 
kms_j)tr->dki_ent _non.enn_constant = TRUE; 
kms_ptr->dki_ent^on.enn_yalue = dap _ent_yalue _alloc(); 
kms_j)tr->dki_ent jon.enn_yalue->ev_yalue = 
var_str _alloc( strlen($l) + 1 ); 
strcpy(kms_ptr->dki_ent ^on.enn_yalue->ev_yalue, $1); 
kms_ptr->dki_ent_jion.enn_yalue->ev jext_yalue = NULL; 

} 

1 FLOAT 
{ 

kmsjptr->dki_entjnon.enn_type = T; 
kms_ptr->dki_ent ^on.enn_totaMength = FLTLength; 
kms_ptr->dki_ent ^on.enn^ange — FALSE; 
kms_ptr->dki_ent jon.enn_num_values = 1; 
kms_jptr->dki_ent^on.enn_constant = TRUE; 
kms_ptr->dki_ent jon.enn_yalue = dap_ent_yalue _alloc(); 
kms_ptr->dki_ent jon.enn_yalue->ev_yalue ~ 
var_str _alloc( strlen($l) -hi); 
strcpy(kms_ptr->dki_ent^on.enn_yalue->ev_yalue, $1); 
kms_jptr->dki_ent_non.enn_yalue->ev^ext_yalue = NULL; 

} 

) 

type_declaration: TYPE 

{ 

curr_op = Typels; 
check^ds = FALSE; 
serror = 2; 

} 

name^d 

{ 

strcpy(temp^ame^d, temp_yalue); 
check^ds = TRUE; 
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serror = 9; 

} 

IS type_definition SEMICOLON 

/* the following switch statement allocates a nonentity */ 

/* derived, or entity node to the schema dependent upon */ 

/* the value of curr_op */ 

{ 

curr_op = Checkids; 
switch (curr_op) 

{ 

case NonEnt: 

ent_non_ptrl = dap_ent ^on _node _alloc(); 
strcpy( ent jon_ptrl->enn ^ame, tempjame_id ); 
ent_non_ptrl->enn_type = kms_ptr->dki_ent_non.enn_type ; 
ent_nonj)trl->ennjbotal_length = 

kms_ptr->dki_ent jon.enn_totaMength ; 
ent ^on _ptrl->enn^ange — kms_ptr->dki_ent ^on.enn_range ; 
ent ^on _ptrl->enn^um_yalues = 

kms_ptr->dki_ent_non.enn_numjvalues ; 
ent^on_ptrl->enn_value = kms_ptr->dki_ent _non.enn_value ; 
kmsj)tr->dki_ent^on.enn_value = NULL; 
ent_non _ptrl->enn_constant = 

kms_ptr->dki_ent _non.enn_constant ; 
ent^on_ptrl->enn ^ext ^ode = NULL; 

ent^on_ptr2 = db_ptr->edn ^nonentity; 

if (ent jon_ptr2 == NULL) 
db_ptr->edn nonentity = ent_jion_ptrl; 
else 
{ 

while (ent_jion_ptr2->enn_next^ode != NULL) 
ent _non_ptr2 = ent_non_ptr2->enn^ext jode; 
ent jon_ptr2->enn _next^ode = ent_non_ptrl; 

} 

ent_non_ptrl = NULL; 
break; 

case Derived: 
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* * 



name 



dernon_ptrl = dap_derjon _node _alloc(); 
strcpy( dernon_ptrl->dnn _name, temp name id ); 
dernon_ptrl->dnn_type = kms_ptr->dki_der non.dnn type ; 
dernon_ptrl->dnn_total_length = 

kms_ptr->dki_der^on.dnn_total_length ; 
dernon_ptrl->dnn_j;ange = kms_ptr->dki_der jon.dnn^ange ; 
dernon_ptrl->dnn jum_values = 

kms_ptr->dki_der^on.dnn jium_yalues ; 
dernon_ptrl->dnn_value = kms_ptr->dki_der ^on.dnn_yalue ; 
kms_ptr->dki_der ^on.dnn_value = NULL; 
dernon_ptrl->dnn _next _node = NULL; 
dernon_ptr2 = db_ptr->edn^onderptr; 
if (dernon_ptr2 == NULL) 
db_ptr->edn^onderptr = dernon_ptrl; 
else 
{ 

while (dernon_ptr2->dnn _next _node != NULL) 
dernon_ptr2 = dernon_ptr2->dnn^ext _node; 
dernon_ptr2->dnn_next ^ode = dernon_ptrl; 

} 

dernon_ptrl = NULL; 
break; 

case Entity: 

/* check if name^jd is on the ent list of the schema */ 

} 

} 

I incomplete_type_declaration 



\d: IDENTIFIER 

/* this rule assigns IDENTIFIER to the variable temp_yalue */ 
/* and inserts it into the id structure of dap^ms^nfo for */ 

/* subsequent comparisons of uniqueness * / 

{ 

strcpy(temp_yalue,$l); 
id_ptr = kms_ptr->dkij,d_ptr; 
if (id j)tr == NULL) 
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{ 

kms_ptr->dki^d_ptr = dap_jdent Jiist _alloc(); 
id_ptr = kms_j)tr->dkwd _ptr; 

} 

else 

{ 

nmove = FALSE; 
new_id_ptr = id_ptr; 
while(id_ptr != NULL) 

{ 

if (strcmp(id_ptr->iljame, temp_yalue) == FALSE) 

{ 

nmove = TRUE; 

} 

else 

{ 

new^d_ptr = id _ptr; 
id_ptr = id_ptr->il_next; 

} 

} 

if((nmove == FALSE) && (curr_op == Checkids)) 

{ 

new_ul_ptr->iljiext = dap^dent_list _alloc(); 
new^d_ptr = new_id_ptr->il jext; 
strcpy (new_id _ptr- > il^ame, temp_value) ; 
new_id _ptr->il jext = NULL; 

} 

else 

{ 

if((nmove == TRUE) (curr_op = Checkids)) 
proc_eval_error(serror) ; 

} 

} 

} 



incomplete_type_declaration: TYPE 
/* entity */ 
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{ 

check^ds = TRUE; 
serror = 3; 

} 

name_id SEMICOLON 

/* At this point a check is made to see if the */ 

/* IDENTIFIER is already in the ent jode. If it */ 
/* is, an error is produced. If it is not, it is */ 

/* added to the schema. */ 



{ 

in = FALSE; 

ent jode_ptrl = db_ptr->edn_entity; 
ent jode_ptr2 = ent^ode_ptrl; 
while (ent^ode_ptr2 != NULL) 

{ 

if (strcmp(ent_node_ptr2->en_jiame, temp_yalue) 

{ 

proc _eval_error(serror); 
in = TRUE; 

} 

else 

ent^ode_ptrl = ent^ode_ptrl->en^ext_ent; 
ent^ode_ptr2 = ent^ode_ptrl; 

} 

if (in == FALSE) 

{ 

ent_jiode_ptr2 = dap_ent^ode _alloc(); 
strcpy(ent^ode_j)tr2->en jame, temp_yalue); 
ent^ode jtr2->en^um_funct = 0; 
ent node ptr2->en terminal = FALSE; 
ent^ode_ptr2->en_ftnptr = NULL; 
ent_jiode_ptr2->en^ext_ent = NULL; 

ent^ode_ptrl = db_ptr->edn_entity; 
ent jode_ptr2 = ent^ode_ptrl; 
if (ent^ode_ptr2 == NULL) 

{ 



== FALSE) 
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db_ptr->edn_entity = ent^ode_ptr2; 
ent ^ode_ptr2 = NULL; 

} 

else 

{ 

while (ent_node_ptr2->en^ext_ent != NULL) 
ent ^ode_ptrl = ent jode_ptrl->en^ext_ent; 
ent jode_ptr2 = ent ^ode_ptrl; 
ent_node_ptrl->en jext_ent = ent_node_ptr2; 
ent jode_ptr2 = NULL; 

} 

} 

check^ds = FALSE; 

} 



type_definition: /* curr_op variables are set for subsequent switch statement */ 
utilization */ 

{ 

curr_op = NonEnt; 

} 

enumeration_type_definition 

{ 

curr_op = NonEnt; 

} 

integer_type_definition 

{ 

curr_op = NonEnt; 

} 

real_type_definition 

I 

{ 

curr_op = Derived; 

} 

derived_type_definition 
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{ 

curr_op = Entity; 

} 

entity_type_definition 

) 

enumeration_type_definition: LP 

/* enumeration dap _kms^nfo structures for */ 

/* nonentity and function nodes are initialized */ 

{ 

check^ds = FALSE; 
switch(curr_op) 

{ 

case NonEnt: 

kms_ptr->dki_ent ^on.enn_type = ’e’; 
kms_ptr->dki_ent ^on.enn^ange = FALSE; 
kms_ptr->dki_ent jon.enn _num_values = 0; 
kms_ptr->dki_ent jon.enn_constant = FALSE; 
break; 

case Function: 

kms_ptr->dki^unct.fn_type = ’e’; 
kms_ptr->dkijunct.fn^ange = FALSE; 
kms_ptr->dki^unct.fn _num_value = 0; 
break; 

} 

} 

enumeration_literal_list RP 

{ 

check^ds = TRUE; 

} 

enumeration_literaMist: enumeration_literal 

/* the pointers are set for value nodes with */ 

/* concurrent incrementation of the number of */ 

/* value nodes present in the nonentity and */ 

/* function structures */ 
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{ 

switch(curr_op) 

{ 

case NonEnt: 

k m s _p t r - > d k i _e n t _n o n . e n n _n u m __v a 1 u e s -f- ; 
kms_ptr->dki_ent_non.enn_yalue — entval_ptr; 
entval_ptr = NULL; 
break; 

case Function: 

kms_ptr->dki_funct.fn^um_yalues-}--|-; 
kms_ptr->dki_funct.fn_yalue = entval_ptr; 
entval_ptr = NULL; 
break; 

} 

} 

enumerationJ^iteraMist COMMA enumeration J_iteral 

{ 

switch(curr_op) 

{ 

case NonEnt: 

kms_ptr->dki_ent^on.enn^um_yalues+-{-; 
entval_ptr2 = kms_ptr->dki_ent^on.enn_yalue 
while (entval_ptr2->ev_next_yalue != NULL) 
entval_ptr2 = entval_ptr2->ev^ext_yalue; 
entval_ptr2 = entval_ptr; 
entval_ptr = NULL; 
break; 

case Function: 

kms_ptr->dki_funct.fn^um_yalue-h-|-; 
entval_ptr2 = kms_ptr->dki^unct.fn_value; 
while (entval_ptr2->ev_next_yalue != NULL) 
entval_ptr2 = entval_ptr2->ev jext_yalue; 
entval_ptr2 = entval^ptr; 
entval_ptr = NULL; 
break; 

} 
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} 



enumeration_literal; name_id 

/* ent_yalue nodes are allocated and the ev_value */ 
/* pointer is set the the appropriate IDENTIFIER */ 

{ 

switch (curr_op) 

{ 

case NonEnt: 

entval_ptr = dap_ent_yalue _alloc(); 
enum_str = var_str _alloc(ENlength 1); 
strcpy(enum_str, temp_yalue); 
entval_ptr->ev_yalue = enum_str; 
entval_ptr->ev_next_yalue = NULL; 
enum^tr = NULL; 

break; 

case Function: 

entval_ptr = dap_ent_yalue _alloc(); 
enum^tr = var_str _alloc(ENlength l); 

strcpy(enum_str, temp^yalue); 
entval_ptr->ev_yalue = enum_str; 
entval_ptr->ev_next_yalue = NULL; 
enum^tr = NULL; 
break; 

} 

} 

I LITERAL_CHARACTER 

{ 

switch (curr_op) 

{ 

case NonEnt: 

entval_ptr = dap_ent_yalue _alloc(); 
enum_str = var_str _alloc( strlen($l) + 1); 
strcpy(enum_str, $1); 
entval_ptr->ev_yalue = enum_str; 
entval_ptr->ev_next_yalue = NULL; 
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enum_str = NULL; 
break; 

case Function: 

entval_ptr = dap_ent_yalue _alloc(); 
enum^tr = var_str _alloc( strlen($l) + 1); 
strcpy(enum_str, $1); 
entval_ptr->ev_yalue = enum^tr; 
entval_ptr->ev^ext_yalue = NULL; 
enum^tr = NULL; 
break; 

} 

} 

integer_type_definition: 

j* integer type dapJcms_ 2 nfo structures are set for */ 

I* subsequent insertion into the schema */ 

{ 

check^ds = FALSE; 
switch (curr_op) 

{ 

case NonEnt: 

kms_ptr->dki_ent ^on.enn_type = ’i’; 
kms _ptr->dki_ent _non.enn^ange = TRUE; 
kms_ptr->dki_ent ^on.enn^um_values = 2; 
kms_ptr->dki_ent ^on.enn_constant = FALSE 
break; 

case Derived: 

kms_ptr->dki_der jon.dnn_type = ’i*; 
kms_ptr->dki_der ^on.dnn^ange = TRUE; 
kms_ptr->dki_der^on.dnn^um_values = 2; 
break; 

case SubNon: 

kms_ptr->dki^ub ^on.snn_type = ’i’; 
kms_ptr->dki^ub^on.snn_range = TRUE; 
kms_ptr->dki^ub^on.snn^um_yalues = 2; 



112 



break; 



case Function; 

kms_ptr->dki_funct.fn_type = *i’; 
kms_ptr->dki^unct.fn_range = TRUE; 
kms_ptr->dki_funct.fn ^um_yalue = 2; 
break; 

} 

} 

integer_range 

{ 

check^ds = TRUE; 

} 

integer_range: RANGE int^ange 

int ganger INTEGER ELIPSES 

/* The kms^nfor value nodes are allocated and initialized */ 

/* dependent upon the state of curr_op. As can be seen from */ 

/* the switch rules which follow, the same sequence must */ 

/* occur for all the allowable types. */ 

{ 

switch (curr_op) 

{ 

case NonEnt: 

kms_ptr->dki_ent_non.enn_value = dap_ent_yalue _alloc(); 
kms_ptr->dki_ent^on.enn_yalue->ev_yalue = var_str _alloc( strlen($2) + 1) 
strcpy(dki_ent_non.enn_yalue->ev_yalue, $2); 
kms_ptr->dki_ent_non.enn_yalue->ev^ext_yalue = NULL; 
kms_ptr->dki_ent^on.enn^um_values-h-h; 
kms_ptr->dki_ent^on.enn_yalue = entval_ptr; 
entvaljptr = NULL; 
break; 

case Derived: 

kms_ptr->dki_der jon.dnn_yalue = dap_ent_yalue _alloc(); 
kms_ptr->dki_der^on.dnn_yalue->ev_yalue = var ^tr _alloc( strlen($2) + 1) 
strcpy(dki _der_non.dnn_yalue->ev_yalue, $2); 
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kms _ptr->dki_der _non.dnn_value->ev ^ext_yalue = NULL; 
kms_ptr->dki _der _non.dnn _jium_values-l-'f ; 
kms_ptr->dki_der _non.dnn_value = entval_ptr; 
entval_ptr = NULL; 
break; 

case SubNon: 

kms_ptr->dki_sub _non.snn_value = dap_ent_yalue _alloc(); 

kms_ptr->dki_sub _non.snn_value->ev_yalue = var_str _alloc( strlen($2) + 1); 

strcpy(dki_sub _non.snn_value->ev_value, $2); 

kms_ptr->dki_sub jon.snn_value->ev _next_yalue — NULL; 

kms_p tr- > dk i_su b_non . sn um_v al ues -f -h ; 

kms_ptr->dki_sub ^on.snn_value = entval_ptr; 

entval _ptr = NULL; 

break; 

case Function: 

kms_ptr">dki^unct.fn_value = dap_ent_yalue _alloc(); 

kms _ptr“>dki_funct.fn_value->ev_yalue = var_str _alloc( strlen($2) H- l); 

strcpy(dki^unct.fn_value->ev_yalue, $2); 

kms_ptr->dkijunct.fn_yalue->ev jext_yalue = NULL; 

kms_ptr->dki_^unct.fn _num_value-i--f ; 

kms_ptr->dki^unct.fn_value = entval_ptr; 

entval_ptr = NULL; 

break; 

} 

} 

INTEGER 

{ 

switch (curr_op) 

{ 

case NonEnt: 

kms_ptr->dki_ent _non.enn_yalue = dap_ent_yalue _alloc(); 

kms_ptr->dki_ent ^on.enn_yalue->ev_yalue = var_str _alloc( strlen($l) H- 1); 

strcpy(dki_ent ^on.enn_yalue->ev_yalue, $1); 

kms_ptr->dki__ent _non.enn_yalue->ev _next_value = NULL; 

kms_ptr->dki_ent _non.enn ^um_values-l~H-; 

entval_ptr2 = kms_ptr->dki_ent ^on.enn_yalue; 

entval_ptr2 = entval_ptr; 
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entval_ptr = NULL; 
break; 

case Derived: 

kms_ptr->dki_der jon.dnn_value = dap_ent_yalue _alloc(); 

kms_ptr->dki_der_non.dnn_yalue->ev_yalue = var_str _alloc( strlen($l) 4- 1); 

strcpy(dki_der jon.dnn_value->ev_yalue, $l); 

kms_ptr->dki_der_jion.dnn_value->ev ^ext_yalue = NULL; 

kmsj)tr->dki_der ^on.dnn^um_values-|-’f; 

entval_ptr2 = kms_ptr->dki_der_non.dnn_value; 

entval_ptr2 = entval_ptr; 

entval_ptr = NULL; 

break; 

case SubNon: 

kms_ptr->dki_sub^on.snn_v’alue = dap_ent_yalue _alloc(); 

kms_ptr->dki_sub jon.dnn_value->ev_yalue = var_str _alloc( strlen($l) ^ 1); 

strcpy(dki_sub^on.snn_yalue->ev_yalue, $1); 

kms j>tr->dki_sub_non.snn_yalue->ev_next_yalue = NULL; 

kms_ptr->dki_sub _non.snn^um_values-l-4‘ ; 

entvalj>tr2 = kms_j>tr->dki_sub_non.snn_yalue; 

entval_ptr2 = entval_ptr; 

entval_ptr = NULL; 

break; 

case Function: 

kms_ptr->dki_funct.fn_value = dap_ent_yalue _alloc(); 

kms_ptr->dki^unct.fn_yalue->ev_yalue = var_str _alloc( strlen($l) -I- 1); 

strcpy(dki^unct.fn_value->ev_value, $1); 

kms_ptr->dki^unct.fn_value->ev_next_yalue = NULL; 

k ms_p t r- > d k i^u n c t . f n_n u m_y al u e -H -h ; 

entval_ptr2 = kms j>tr->dki_funct.fn_yalue; 

entval_ptr2 = entval_ptr; 

entval_ptr = NULL; 

break; 

} 

} 

) 

real_type_definition: 
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{ 

check^ds = FALSE; 
switch (curr_op) 

{ 

case NonEnt: 

kms_ptr->dki_ent^on.enn_type = T; 
kms_ptr->dki_ent^on.enn^ange = TRUE; 
kms_ptr->dki_ent_non.enn_num_values = 2; 
kms_ptr->dki_ent jon.enn_constant = FALSE; 
break; 

case Derived: 

kms_ptr->dki_der^on.dnn_type = T; 
kms_ptr->dki_der_non.dnn_range = TRUE; 
kms_ptr->dki_der^on.dnn^um_values = 2; 
break; 

case SubNon: 

kms_ptr->dki^ub_non.snn_type = T; 
kms_ptr->dki_sub^on.snn^ange = TRUE; 
kms_ptr->dki_sub^on.snn^um_yalues = 2; 
break; 

case Function: 

kms_ptr->dkijunct.fn_type — T; 
kms_ptr->dki_funct.fn_range = TRUE; 
kms_ptr->dki_funct.fn jum_yalue = 2; 
break; 

} 

} 

float j;ange 

{ 

check^ds = TRUE; 

} 

j 

float_range: RANGE FLOAT ELIPSES 

{ 

switch (curr_op) 

{ 
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case NonEnt: 

kms_ptr->dki_ent_non.enn_value = dap_ent_yalue _alloc(); 
kms_ptr->dki_ent jon.enn_yalue->ev_yalue = var ^tr _alloc( strlen($2) 4- 1); 
strcpy(dki_ent^on.enn_value->ev_yalue, $2); 
kms_ptr->dki_ent jon.enn_value->ev^ext_yalue = NULL; 
kms_j)tr->dki_ent^on.ennjrium_values++; 
kms_ptr->dki_ent_non.enn_value = entval_ptr; 
entval_ptr = NULL; 
break; 

case Derived: 

kms_ptr->dki_der^on.dnn_value = dap_ent_value _alloc(); 
kms_ptr->dki_der_non.dnn_value->ev_yalue = vax_str _alloc( strlen($2) -|- 1); 
strcpy (dki_der^on.dnn_value->ev_yalue, $2) ; 
kms_j)tr->dki_derjrion.dnn_value->ev^ext_yalue = NULL; 
kms_ptr->dki_derjon.dnn jum_yalues-f-f; 
kms_ptr->dki_derj[ion.dnn_value = entval_ptr; 
entval_ptr = NULL; 
break; 

case SubNon: 

kms_ptr->dki_subj[ion.snn_value = dap_ent_value _alloc(); 
kms_ptr->dki_subj[ion.snn_yalue->ev_yalue = var_str _alloc( strlen($2) -f- 1); 
strcpy(dki_subjnon.snn_value->ev_value, $2); 
kms_ptr->dki_subjrion.snn_yalue->ev^extjvalue = NULL; 
kms_ptr->dki_subjrion.snn_num_yalues-f-f ; 
kms_ptr->dki_sub^on.snn_value = entval_ptr; 
entval_ptr = NULL; 
break; 

case Function: 

kms_ptr->dki^unct.fn_value = dap_ent_yalue _alloc(); 

kms_j)tr->dki^unct.fn_value->ev_yalue = var _str _alloc( strlen($2) 4- 1); 

strcpy(dki^unct.fn_yalue->ev_valuej $2); 

kms_ptr->dki_funct.fn_value->ev^ext_value = NULL; 

kms_pt r- > d k i J[u net .fn jum_y alue4- 4- ; 

kms_ptr->dki^unct.fn_value = entval_ptr; 

entval_ptr = NULL; 

break; 

} 
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} 

FLOAT 

{ 

switch (curr_op) 

{ 

case NonEnt: 

kms_ptr->dki_ent_non.enn_yalue = dap _ent_yalue _alloc(); 

kms_ptr->dki_ent_non.enn_yalue->ev_yalue = var_str _alloc( strlen($l) -}- 1); 

strcpy(dki_ent jon.enn_yalue->ev_yaIue, $1); 

kms_ptr->dki_ent_non.enn_yalue->ev_next_value = NULL; 

kms_ptr->dki_ent jon.enn_num_yalues+-h; 

entval_ptr2 = kms_ptr->dki_ent_non.enn_yalue; 

entval_ptr2 = entvaljtr; 

entvaljtr = NULL; 

break; 

case Derived: 

kms_ptr->dki_der_non.dnn_value = dap_ent_value _alloc(); 

kms_ptr->dki_der jon.dnn_yalue->ev_yalue = var ^tr _aIloc( strlen($l) -h l); 

strcpy(dki_der jon.dnn_value->ev_yalue, $1); 

kms_j)tr->dki_der^on.dnn_yalue->ev_next_yalue = NULL; 

kms_ptr->dki_der jon.dnn_num_yalueS'f'f ; 

entval_ptr2 = kms_ptr->dki _der _non.dnn_value; 

entval_ptr2 = entval_ptr; 

entvaljtr = NULL; 

break; 

case Subnon: 

kms_ptr->dki_sub^on.snn_yalue = dap_ent_yalue _alloc(); 

kms_ptr->dki_sub jon.snn_value->ev_yalue = var_str _alloc( strlen($l) -h 1); 

strcpy(dki_sub jon.snn_value->ev_yalue, $1); 

kms_ptr->dki_sub_non.snn_value->ev_jiext_yalue = NULL; 

k ms_pt r- > d k i_s u b_n o n . s n n_ji u m_v a 1 u es + -j- ; 

entval_ptr2 = kms_ptr->dki_sub jon.snn_value; 

entval_ptr2 = entvaljptr; 

entval_ptr = NULL; 

break; 

case Function: 

kms_ptr->dki^unct.fn_value = dap_ent_yalue _alloc(); 
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kms_ptr->dki_funct.fn_value->ev_yalue = var_str _alloc( strlen($l) + 1) 

strcpy(dki_funct.fn_value->ev_yalue, $1); 

kms_ptr->dki_funct.fn_value->ev_next_yalue = NULL; 

k m s _p t N > d k i _f u n c t . f n _n u m _y a 1 u e -h -h ; 

entval_ptr2 = kms_ptr->dki_funct.fn_yalue; 

entval_ptr2 = entval_ptr; 

entvaljtr = NULL; 

break; 

} 

} 

> 

derived_type_defintion: NEW 

/* the nonentity, subtype nonentity, and derived type */ 

/* nonentity nodes are examined to find which con- */ 

/* the current value of IDENTIFIER */ 

{ 

curr_op = Derived; 
check^ds = FALSE; 

} 

name^d 

{ 

non_ent_ptrl = db_ptr->edn_nonentity; 
non_entjptr2 = non_ent_ptrl; 
subnon_ptrl = db_ptr->edn_nonsubptr; 
subnon_ptr2 = subnon_ptrl; 
dernon^ptrl = db_ptr->edn_nonderptr; 
dernon_ptr2 = dernon_ptrl; 
ini = FALSE; 
in2 = FALSE; 
in3 = FALSE; 

while ((non_ent_ptr2 != NULL) && (ini == FALSE)) 

{ 

if(strcmp(non_ent_j)tr2->ennjriame, temp_yalue) == FALSE) 

{ 

ini = TRUE; 

strcpy(temp, temp_value); 

} 
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else 



{ 

non_ent_ptrl = non_ent_ptrl->enn jext^ode; 
non_ent_ptr2 = non_ent_ptrl; 

} 

} 

while ((subnon_ptr2 != NULL) && (ini == FALSE) && (in2 == FALSE)) 

{ 

if(strcmp(subnon_ptr2“>snn jame, temp_value) == FALSE) 

{ 

in2 = TRUE; 
strcpy(temp, temp^yalue); 

} 

else 

{ 

subnon_ptrl = subnon_ptrl->snn jext jode; 
subnon_ptr2 = subnon_ptrl; 

} 

} 

while ((dernon_ptr != NULL) && (ini == FALSE) &.&. (in2 == FALSE) && 

(in3 == FALSE)) 

{ 

if(strcmp(dernon_ptr2->dnn jame, temp_yalue) == FALSE) 

{ 

in3 = TRUE; 
strcpy(temp,temp_yalue); 

} 

else 

{ 

dernon_ptrl = dernon_ptrl->dnn jext ^ode; 
dernon_ptr2 = dernon_ptrl; 

} 

} 

} 

derived^ange 

{ 

check_ids = TRUE; 

} 
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derived^ange: lnteger_type_definition 

/* the type is now checked to see if in fact the type field */ 

/* in the kms^nfo structure actually contains the value */ 

/* identified in derived_type_definition above */ 

{ 

if (ini == TRUE) 

{ 

if(strcmp(kms_ptr->dki_ent^on.enn^ame, temp) != FALSE) 
proc_eval_error(serror) ; 

} 

else 

{ 

if (in2 == TRUE) 

{ 

if(strcmp(kms_ptr->dki_sub^on.snn jame, temp) != FALSE) 
proc_eval_error(serror) ; 

} 

else 

{ 

if (inS == TRUE) 

{ 

if(strcmp(kms_ptr->dki_der_non.dnn _name, temp) != FALSE) 
proc_eval_error(serror) ; 

} 

else 

{ 

proc_eval_error(serror) ; 

} 

} 

} 

} 

I real_type_definition 

{ 

if (ini == TRUE) 

{ 

if(strcmp(kms_ptr->dki_ent^on.enn _name, temp) != FALSE) 
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proc_eval_error(serror) ; 



} 

else 

{ 



if (in2 == TRUE) 

{ 

Lf(strcmp(kms_ptr->dki_sub_non.snnjiame, temp) != FALSE) 
proc_eval_error(serror) ; 

} 

else 

{ 

if (in3 == TRUE) 

{ 

if(strcmp(kms_ptr->dki_der jon.dnnjiame, temp) != FALSE) 
proc_eval_error(serror) ; 

} 

else 

{ 

proc_eval_error(s error); 

} 

} 



entity_type _definition: EMPTY 
I ENTITY 
{ 

check^ds = TRUE; 

} 

entity _component_declaration^ist 

{ 

check_ids = FALSE; 

} 

end_entity 



entity_component_declaration_list: entlty_component_declaxation 

I entity_component_declatation_list entity^component 



declatation 
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end jentity: END 

1 END ENTITY 



entity_componen t^declatation : 

{ 

serror = 5; 

} 

************* identifier Jist COLON 

{ 

check_ids = FALSE; 

} 

function_type default_yalue SEMICOLON 



function_type: common_type 

1 FLOAT 

{ 

kms_ptr->dkij^unct.fn_type = T; 
kms_ptr->dki_funct.fn_range = FALSE; 
kms_ptr->dki_funct.fn_total_length = FLTlength; 
kms_ptr->dki^unct.fn_num_yalue = 0; 
kms_ptr->dki_funct.fn_yalue = NULL; 
kms_ptr->dkijunct.fn_entptr = NULL; 
kms_ptr->dki_funct.fn_subptr = NULL; 
kms_ptr->dkij^unct.fn _nonentptr = NULL; 
kms_ptr->dki_funct.fn jonsubptr = NULL; 
kms_ptr->dki_funct.fn_nonderptr = NULL; 
kms_ptr->dki_funct.fn_next^ntptr = NULL; 
kms_ptr->dki_funct.fn_entnull = FALSE; 
kms_ptr->dki_funct.fn_unique = FALSE; 

} 

I INTEGER 

{ 

kms_ptr->dki_funct.fn_type = ’i’; 
kms_ptr->dki_funct.fn^ange = FALSE; 
kms_ptr->dkiJ[unct.fn_totaMength = INTlength; 
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common 



kms_ptr->dki_funct.fn_num_yalue = 0; 
kms_ptr->dki_funct.fn_value = NULL; 
kms_ptr->dki^unct.fn_entptr = NULL; 
kms_ptr->dki_funct.fn_subptr = NULL; 
kms_ptr->dkiJ|unct.fn^onentptr = NULL; 
kms_ptr->dki^unct.fn _nonsubptr = NULL; 
kms_ptr->dki_funct.fn jonderptr = NULL; 
kms_ptr->dki^unct.fn _next_fntptr = NULL; 
kms_ptr->dki_funct.fn_entnull = FALSE; 
kms_ptr->dki_funct.fn_unique = FALSE; 

} 

i BOOLEAN 
{ 

kms_ptr->dki_funct.fn_type = ’b’; 
kms_ptr->dki_funct.fn_j;ange = FALSE; 
kms_ptr->dki_funct.fn_totalJ^ength = BOOLlength; 
kms_ptr->dki_funct.fn jum_yalue = 0; 
kms_ptr->dki^unct.fn_yalue = NULL; 
kms_ptr->dki^unct.fn_entptr = NULL; 
kms_ptr->dkij^unct.fn_subptr = NULL; 
kms_ptr->dki_funct.fn _nonentptr = NULL; 
kms_ptr->dki_funct.fn_nonsubptr = NULL; 
kms_ptr->dkiJnnct.fn_nonderptr = NULL; 
kms_ptr->dki_funct.fn jext_fntptr = NULL; 
kms_ptr->dki_funct.fn_entnull = FALSE; 
kms_ptr->dki_funct.fn_unique = FALSE; 

} 

I set_type _definition 



type: enumeration_type_definition 

integer_type_definition 

real_type_definition 

name^d 

{ 

non_ent_j)trl = db_ptr->edn jonentity; 
non_ent_ptr2 = non_ent_ptrl; 
ent_ptrl = db_ptr->edn_entity; 
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entjptr2 = ent_j>trl; 

gen_ptrl = db_j)tr->edn_subptr; 

gen_ptr2 = gen_ptrl; 

subnonjptrl = db_ptr->edn jonsubptr; 

subnon_ptr2 = subnonjptrl; 

dernon^trl = db_jptr->edn_nonderptr; 

dernon_ptr2 = dernon_ptrl; 

ini = FALSE; 

in2 = FALSE; 

in3 = FALSE; 

in4 = FALSE; 

in5 = FALSE; 

while ((nonjent_j)tr2 != NULL) (ini == FALSE)) 

{ 

if(strcmp(non_ent_ptr2->ennjiame, temp_yalue) == FALSE) 

{ 

ini = TRUE; 
strcpy(temp, temp_yalue); 

} 

else 

{ 

nonjentjptrl = nonjent_j>trl->ennjiext_node; 
non_ent_j>tr2 = non_ent_jptrl; 

} 

} 

while ((subnon_ptr2 != NULL) k&a (ini == FALSE) && (in2 == FALSE)) 

{ 

if(strcmp(subnon_j)tr2->snnj|iame, temp_yalue) == FALSE) 

{ 

in2 = TRUE; 
strcpy(temp, temp_yalue); 

} 

else 

{ 

subnonjptrl = subnon^trl->snnjiext jiode; 
subnon_j)tr2 = subnonjptrl; 

} 

} 
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while ((dernon_ptr2 != NULL) && (ini == FALSE) && (in2 == FALSE) && (in3 
== FALSE)) 

{ 

if(strcmp(dernon_ptr2->dnn^ame, temp_value) == FALSE) 

{ 

in3 = TRUE; 
strcpy(temp,temp_yalue); 

} 

else 

{ 

dernon_ptrl = dernon_ptrl->dnn^ext_node; 
dernon_ptr2 = dernon_ptrl; 

} 

} 

while((gen_ptr2 != NULL) && (ini == FALSE) && (in2 — FALSE) && (in3 == 
FALSE) && (in4 == FALSE)) 

{ 

if(strcmp(gen _ptr2->gsn_name, temp_yalue) == FALSE) 

{ 

in4 = TRUE; 

strcpy (temp, temp^yalue); 

} 

else 

{ 

gen_ptrl = gen_ptrl->gsn_next_jenptr; 
gen_ptr2 = gen j>trl; 

} 

} 

while((ent_ptr2 != NULL) && (ini == FALSE) && (in2 == FALSE) && (in3 == 
FALSE) && (in4 == FALSE) && (inS == FALSE)) 

{ 

if(strcmp(ent_ptr2->en_name, temp_value) == FALSE) 

{ 

in5 = TRUE; 

Strcpy (temp, temp_value); 

} 

else 

{ 
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ent_ptrl = ent_ptrl->en jext_ent; 
ent_ptr2 = ent_ptrl; 

} 

} 

if (ini == TRUE) 

{ 

func_ptrl->fn _nonentptr = non_ent _ptr2; 
kms_ptr->dki^unct.fn_type = V’; 

} 

else 

{ 

if (in2 == TRUE) 

{ 

func _ptrl->fn^onsubptr = subnon_ptr2; 
kms_ptr->dki^unct.fn_type = ’w’; 

} 

else 

{ 

if (inS == TRUE) 

{ 

func_ptrl->fn^onderptr = dernon_ptr2; 
kms_ptr->dki^unct.fn_type = ’x’; 

} 

else 

{ 

if (in4 == TRUE) 

{ 

func j)trl->fn_subptr = gen_ptr2; 
kmsj)tr->dki^unct.fn_type = ’y’; 

} 

else 

{ 

if(in5 == TRUE) 

{ 

func _ptrl->fn_entptr = ent_ptr2; 
kms_ptr->dkij^unct.fn_type = ’z’; 

} 

else 
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{ 

proc _eval_error(serror); 

} 

} 

} 

} 

} 

} 

string_rule 



string_rule: STRING LP 

{ 

kms _ptr->dki_funct.fn_type = ’s’; 
kms j)tr->dki^unct.fn^ange = TRUE; 
kms _ptr->dki_funct.fn_num_value = 2; 

} 

int^ange RP 

j 

set_type_definition: SET OF commmon_type 

{ *********** kms_j)tr->dki_funct.fn_type = toupper(kms_ptr- 

>dki^unct.fn_type); 

} 

? 

default_value: empty 

I ASSIGN simple _const SEMICOLON 
? 

identifier^ist: name_id 

{ 

temp_j)tr = kms_ptr->dki_temp_j)tr; 
free^dent_list (temp_ptr) ; 

kms_ptr->dkijtemp_j)tr = dap_ident_list _alloc(); 
temp_ptr = kms_ptr->dkijtemp_ptr; 
strcpy(temp_ptr->il ^ame, temp_yalue); 
temp_ptr->il_next = NULL; 

} 

I identifier^ist COMMA name_id 
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{ 

new_temp_ptr = temp_ptr; 
while (new_temp_ptr->il_next != NULL) 
new_temp_ptr = new_temp_ptr->ilj[iext; 
new_temp_ptr->il_next = dap^dent^ist _alloc(); 
new_temp_ptr = new_temp_ptr->il_next; 
strcpy(new_temp_ptr->il jame, temp_yalue); 

= NULL; 

} 



subtype _declaration: SUBTYPE 

{ 

curr_op = SubTypels; 
check_ 2 ds = TRUE; 
serror = 7 ; 

} 

name_J_d 

{ 

serror = 8; 
check_jds = FALSE; 

} 

IS subtype_j^ndication SEMICOLON 
I SUBTYPE 
{ 

check_ 2 ds = FALSE; 
curr_op = SubTypels; 
serror = 10; 

} 

name^d 

{ 

gen_ptrl = db_ptr->edn_subptr; 
genj)tr2 = gen_ptrl; 
ini = FALSE; 

while ((gen_ptr2 != NULL) (ini == FALSE)) 

{ 

if (strcmp(gen_ptr2->gsn_name, temp_yalue) == FALSE) 
ini = TRUE; 
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else 

{ 

gen_ptrl = gen_ptrl->gsn jext_genptr; 
gen_ptr2 = gen_ptrl; 

} 

} 

if (ini == FALSE) 
proc_eval_error(serror) ; 

} 

IS namel J_ist 

{ 

ini = FALSE; 
in2 = FALSE; 
in3 = FALSE; 

namel_ptrl = kmsjptr->dki ^ameljptr; 
namel_j)tr2 = namel_ptrl; 
genjptrl = dbjptr->edn_subptr; 
genjptr2 — gen_ptrl; 

overlapsub_ptrl = gen jptrl->gsn_subptr; 
overlapsubjptr2 = overlapsubjptrl; 
while (namel_ptr2 != NULL) 

{ 

while ((genjptr2 != NULL) && (ini == FALSE)) 

{ 

if (strcmp(gen_ptr2->gsn ^ame, namel_ptr2->il ^ame) == FALSE) 

{ 

ini = TRUE; 
in2 = TRUE; 

if (overlapsub_ptr2 == NULL) 

{ 

genjptrl — gen_ptrl->gsn_subptr; 
genjptr2 = gen_ptrl; 

genjptr2 = dap_overlap_sub^ode _alloc(); 
overlapsubjptrl = gen_ptr2; 
overlapsubjptr2 = overlapsub_ptrl; 
namel jptr2->il_name = overlapsubjptr2; 
overlapsub_ptr2->osn^ame = namel_ptr2->ilj[iame; 
overlapsub_j)tr2->oen^ext ^ame = NULL; 
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} 

else 

{ 

while (overlapsub_ptr2->oen_name != NULL) 
overlapsub_ptr2 = overlapsub_ptr2->oen jext jame; 
overlapsub_ptr2->oen^ext jame = dap_overlap_sub jode _alloc(); 
overlapsub_ptrl = overlapsub_ptr2->oen^ext^ame; 
overlapsub_ptr2 = overlapsub_ptrl; 
namel_ptr2->il jame = overlapsub_ptr2; 
overlapsub_ptr2->osn jame = namel_ptr2->il^ame; 
overlapsub_ptr2->oen jext jame = NULL; 

} 

} 

else 

{ 

gen_ptrl = gen_ptrl->gsn_next_genptr; 
gen_ptr2 = gen_ptrl; 

} 

} 

ent_ptrl — db_ptr->edn_entity; 
ent_ptr2 = ent_ptrl; 

overlapent_ptrl = gen_ptrl->gsn_entptr; 

overlapent_ptr2 = overlapent_ptrl; 

while ((ent_ptr2 != NULL) &:&: (in3 == FALSE)) 

{ 

if (strcmp(ent_ptr2->gsn_name, namel_ptr2->il jame) == FALSE) 

{ 

in3 = TRUE; 
in4 = TRUE; 

if (overlapsub_ptr2 == NULL) 

{ 

gen_ptrl = gen_ptrl->gsn_entptr; 
gen_ptr2 = gen_ptrl; 

gen_ptr2 = dap_overlap_ent_node _alloc(); 
overlapent_ptrl = gen_ptr2; 
overlapent_ptr2 = overlapent_ptrl; 
namel_ptr2->il^ame = overlapent_ptr2; 
overlapent_ptr2->oen jame = namel_ptr2->il^ame; 
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overlapent_ptr2->oen jext ^ame = NULL; 

} 

else 

{ 

while (overlapent_ptr2->oen jame != NULL) 
overlapent_ptr2 = overlapent_ptr2->oen_next_name; 
overlapent_ptr2“>oen_next jame = dap_overlap_ent_node _alloc(); 
overlapent_ptrl = overlapent_ptr2->oen_next_name; 
overlapent_ptr2 = overlapent j>trl; 
namel _ptr2->il^ame = overlapent _ptr2; 
overlapent_ptr2->oen_name — namel_ptr2->il_name; 
overlapent_ptr2->oen_next^ame = NULL; 

} 

} 

else 

{ 

entjtrl = ent_ptrl->en jext_ent; 
ent_ptr2 = ent_ptrl; 

} 

} 

if ((in2 == FALSE) kSi (in4 == FALSE)) 
proc_eval_error(serror) ; 
else 
{ 

ini = FALSE; 
in2 = FALSE; 
in3 = FALSE; 
in4 = FALSE; 

gen_ptrl = db_ptr->edn_subptr; 
gen_ptr2 = gen_ptrl; 
namel_ptrl = namel_ptrl->il_next; 
namel_ptr2 = namel_ptrl; 

} 

} 

check^ds = TRUE; 

} 

******** entity Jype _defmition SEMICOLON 
I incomplete_subtype_declajation 
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subtype^ndication: name_id subtype_derinition 
> 

subtype_definition: RANGE enumeration_literal ELIPSES enumeration_Jiteral 
I integer_type_definition 
I real_type_defmition 
I empty 
{ 

node_type = find_previous(temp_yalue, non_ent_ptrl, subnon_ptrl, dernon_ptrl); 

switch ( nod e_type) 

{ 

case NonEnt: 

subnon_ptrl = dap_sub^on^ode _alloc(); 
strcpy(subnon_ptrl->snn^ame, ent jon_ptrl->enn^ame); 
subnon_ptrl->snn_type = ent _non_ptrl->enn_type; 
subnon_ptrl->snn_total_l^ength = ent jon_ptrl->enn_totaMength; 
subnon_ptrl->snn_range = ent jon_ptrl->enn_range; 
subnon-ptrl->snn^um_values = ent^on_ptrl->enn^um_yalues; 
subnon_ptrl->snn_yalue = ent jon_ptrl->enn_value; 
subnon_ptrl->snn_next^ode = ent jon_ptrl->enn^ext^ode; 
subnon_ptrl = db_ptr->edn_nonsubptr; 
subnon_ptr2 = subnon_ptrl; 
if (subnonj)tr2 == NULL) 
db_ptr->edn jonsubptr = subnon_ptrl; 
else 
{ 

while (subnon_ptr2->snn_next_node != NULL) 
subnon_ptr2 = subnon_ptr2->snn jext jode; 
subnon_ptr2->snn jext^ode = subnon_ptrl; 

} 

subnon^ptrl = NULL; 
break; 

case Derived: 

subnon_ptrl = dap_sub^on jode _alloc(); 
strcpy(subnon_ptrl->snn^ame, dernon_ptrl->dnn jame); 
subnon_ptrl->snn_type = dernon_ptrl->dnn_type; 
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subnon_ptrl->snn_totaMength = dernon_ptrl->dnn_totaMength; 
subnon_ptrl->snn_range = dernon_ptrl->dnn^ange; 
subnon-ptrl->snn jum_values = dernon_ptrl->dnn_num_values; 
subnon_ptrl->snn_value = dernon_ptrl->dnn_value; 
subnon_ptrl->snn^ext jode = dernon_ptrl->dnn^ext^ode; 
subnon_ptrl = db_ptr->edn jonsubptr; 
subnon_ptr2 = subnonjptrl; 
if (subnon_ptr2 == NULL) 
db_ptr->edn jonsubptr = subnon_ptrl; 
else 
{ 

while (subnon_ptr2->snn^ext^ode != NULL) 
subnon_ptr2 = subnon_ptr2->snn jext ^ode; 
subnon_ptr2->snn jext_node = subnon_ptrl; 

} 

subnon_ptrl = NULL; 
break; 

case SubNon: 

subnon_ptrl = dap^ub^on ^ode _alloc(); 
strcpy(subnon_ptrl->snn^ame, subnon_ptrl->snn _name); 
subnon_ptrl->snn_type = subnon_ptrl->snn_type; 
subnon_ptrl->snn_totaMength = subnon_ptrl->snn_totaMength; 
subnon_ptrl->snn^ange = subnon_ptrl->snn^ange; 
subnon-ptrl->snn^um_values = subnon_ptrl->snn^um_values; 
subnon_ptrl->snn_value = subnon_ptrl->snn_value; 
subnon_ptrl->snn jext _node = subnon_ptrl->snn ^ext jode; 
subnon_ptrl = db_ptr->edn jonsubptr; 
subnon_ptr2 = subnon^ptrl; 
if (subnon_ptr2 == NULL) 
db_ptr->edn jonsubptr = subnon_ptrl; 
else 
{ 

while (subnon_ptr2->snn jext_node != NULL) 
subnon_ptr2 = subnon_ptr2->snn jext _node; 
subnon_ptr2->snn _next _node = subnon_ptrl; 

} 

subnon_ptrl = NULL; 
break; 
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} 



} 



type_mark: namel 

I predefined_tm 

namel_list: namel 

{ 

temp_ptr = kms_ptr->dki_temp_ptr; 
free_ident_list(temp_ptr); 

kms_ptr->dki_temp_ptr = dap_ident_list _alloc(); 
temp_ptr = kms_ptr->dki_temp_ptr; 
strcpy(temp_ptr->il _name, temp_value); 
temp_ptr->il _next = NULL; 

} 

I namel_list COMMA namel 

{ 

new_temp_ptr = temp_ptr; 
while (new_temp_ptr->il ^ext != NULL) 
new_temp_ptr = new_temp_ptr->il _next; 
new_temp_ptr->il _next — dap^dent_list _alloc(); 
new_temp_ptr = new_temp_ptr->il __next; 
strcpy(new_temp_ptr->il _name, temp_value); 
new_temp_ptr->il _next = NULL; 

} 

namel: name_id 

I selected_component 

predefmed_tm: STRING /* for type values in declaration */ 
I INTEGER 
I BOOLEAN 
I FLOAT 
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ada_range: simple_expression ELIPSES simple_expression 



incomplete_subtype_declaration: SUBTYPE 

{ 

check_|ds = TRUE; 

} 

/* entity */ 
name_j^d SEMICOLON 
{ 

in = FALSE; 

gen_ptrl = db_ptr->edn_subptr; 
while (gen_ptrl != NULL) 

{ 

if (strcmp(gen_ptrl->gsn_name, temp_value) == FALSE) 

{ 

proc_eval_error(serror); 
in = TRUE; 

} 

else 

gen_ptrl = gen_ptrl->gsn jext_genptr; 
gen_ptr2 = genjptrl; 

} 

if (in == FALSE) 

{ 

gen_ptr2 = dap_gen_node _alloc(); 
strcpy(gen_ptr2->gsn_name, temp_yalue); 
gen_ptr2->gsn_numjunct = 0; 
genjptr2->gsn_terminal = FALSE; 
gen_ptr2->gsn_entptr = NULL; 
gen_ptr2->gsn_num_ent = NULL; 
genjptr2->gsn jtnptr = NULL; 
gen_ptr2->gsn_subptr = NULL; 
gen_ptr2->gsn _num_sub = 0; 
gen_ptr2->gsn_next_genptr; 

gen_ptrl = db_ptr->edn_subptr; 
genjptr2 = gen_ptrl; 
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if (gen_ptr2 == NULL) 

{ 

db_ptr->edn^ubptr = gen_ptrl; 
gen_ptr2 = db_ptr->edn_subptr; 
gen_ptr2 = NULL; 

} 

else 

{ 

gen_ptrl = db_ptr->edn_subptr; 
gen_ptr2 = gen_ptrl; 

while (gen_ptr2->gsn^ext_genptr != NULL) 
gen_ptr2 = gen_ptr2->gsn ^ext_genptr; 
gen_ptrl->gsn ^ext_genptr = gen_ptr2; 
gen_ptr2 = NULL; 

} 

} 

check^ds = FALSE; 

} 

» 

null_value _constraint: WITHNULL 
I WITHOUTNULL 



selected _component: IDENTIFIER DOT IDENTIFIER 
) 

attribute: type^nark HYPHEN LP loop_parameter RP 

{ 

} 

1 type^nark HYPHEN attribute_j^dentifier LP ada_expresssion RP 

attribute_identifier: IMAGE 
I VAL 
I POS 
I VALUE 

literal: NUMERIC_JjITERAL /* for user default type values in declaration * / 
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I L1TERAL_CHARACTER 
I CHARACTER _STR1NG 
I NULL 
I TRUE 
I FALSE 

named _aggregate: LP 

{ 

} 

component _association^ist RP 
I EMPTY /* to handle case when no attributes listed in */ 
/* CREATE due to LR(l) grammar */ 



component _association_list: component _association 

{ 

I component _association^ist COMMA component _association 
> 

component _association: identifier_choice 

{ 

CREATE: 

} 

IMPLY ada_expresssion 

identifier_choice: IDENTIFIER 

{ 

} 

I identifier_choice IDENTIFIER 

ada_expression: relation 
I rel_or^ist 
I rel _xor^ist 
I rel _and_then^ist 
I rel_or_else_list 

rel and list: relation AND relation 
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I rel ^nd_[ist AND relation 

j 

rel_or_Jist: relation OR relation 
I rel_or_Jist OR relation 

rel _xorJ_ist: relation XOR relation 
I rel _xor J_ist XOR relation 

rel _and_then_l_ist: relation AND THEN relation 

I rel _and_then Jist AND THEN relation 



rel_or_else_list: relation OR ELSE relation 

I rel_or_else^ist OR ELSE relation 
; relation: simple_expression 

{ 

CREATE: 

(FOR I FOR EACH) & DESTROY 
relational_operator 
CREATE: 

(FOR I FOR EACH) k DESTROY: 
simple_expression 
I expr^n_op ada^ange 
I expr^n_type _mark 
1 simple_expression test_set 
I quantification_clause_list simple_expression 

simple_expression: term^ist 

I unary _operator term^ist /* probably won’t use since */ 
I set_exp_J_ist /* involves expressions */ 

set_exp^ist: primary set_operator primary 
I set_exp^ist set_operator primary 

primary: ada_name2 
I prim ary 2 
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primary2: literal 

{ 

/♦ NUMER1C_LITERAL | LITERAL_CHARACTER | CHARACtER_STRING | */ 
r NULL I TRUE | FALSE */ 

} 

I set_constructor 
I LP ada _expression RP 
I indexed_component 
) 

/* &c type_conversion is handled by indexed_component * / 

indexed_component: adajame 
> 

ada^ame: adajame2 

I indexed_component 
) 

adajame2; type^riark 

/* -> namelj predefined_tin(b,s,i,f) */ 

I function_call 



term^ist: term 

I termjist adding_operator term 



term: factor list 



factor^ist: factor 

I factor_list multiplying_operator factor 



factor: primary 

I primary EXPONENT prim 2 o*y 



quantification_clause_list: quantification_clause COLON 
I qu an tific at ion_clau sexist 
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quantification_clause COLON 



quantification_clause: FOR quantifier IDENTIFIER IN domain 

quantifier: SOME 
I EVERY 
I NO 

domain: primary 

I primary WHERE 

I and ((simple_expl^ist 2nd_on^impIe_expl^ist simple_exp2^ist) | 

I and ((simple_expl^ist 2nd_on^imple_expl J^ist simple_exp2^ist) | 

> 

expr^n_op: simple_expression 
CREATE: 

in_op 

) 

expr^n_type^7iark: expr^n_op type^riark 



test_set: isin_operator primary 
I is _op ExMPTY 
) 

relational_operator: = 

I /= 

I &< 

I &<= 

I &> 

I &>= 

I EQ 
I NE 
I NQ 
I LT 
I LE 

I lq 
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I GT 
I GE 
I GQ 

adding_operator: H- 

I - 

I kSi /* concat */ 

unary _operator: arith_unary _op 
I log_unary_op 

arith_unary_op: + 



log_unary_op: NOT 
> 

multiplying_operator: * 

I / 

I MOD 

I REM /* remainder */ 
) 

in_op; IN 
I NOT IN 

J 

is_op; IS 
i IS NOT 

isin_operator: is_op IN 

set_operator: UNION 
I diff_op 
I inter_op 
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diff _op; DIFF | DIFFERENCE 

inter_op: INTER 

I INTERSECT 
I INTERSECTION 

set_constructor: 

LCB 

RGB 

I LCB RGB /* empty or null list * / 

I LCB 

I LCB expr_in_op primaxy2 WHERE condition RGB 

/* because of primary2, probably not for CREATE */ 

> 

function_call: predefined_function_call 
) 

predefined_function_call: function^ame 
I attribute 
> 

aggregate _^gument: primary 

I IDENTIFIER DUPLICATES LP primary RP 

function_name: COUNT 
I SUM 
I AVG 
I MIN 
I MAX 

. ************************************************************* 

End of ddl statement ************************************************************* 

dml_statement: simple_statement 
I compound_statement 



simple_statement: exit_statement 
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assignment_statement 

ere ate_statement 

include_statement 

exclude^statement 

destroy_statement 

move_statement 

procedure_call 



exit statement: EXIT end exit SEMICOLON 



end _exit: IDENTIFIER 
I WHEN condition 
I IDENTIFIER WHEN condition 



assignment_statement: indexed_component ASSIGN ada_expression 



create_statement: CREATE NEW 

{ 

check^ds = FALSE; 

} 

namel^ist 

{ 

temp_ptr = kms_ptr->dki_temp_ptr; 
while (temp_ptr != NULL) 

{ 

ini = FALSE; • 

ent_ptrl = db_ptr->edn_entity; 

while ((ent_ptrl != NULL) &&: (ini == FALSE)) 

{ 

if (strcmp(temp_ptr->il ^ame, ent_ptrl->en jiame) == FALSE) 

{ 

create_listl = dap_create_list _alloc(); must create 
create_listl->dcl jriodejtype = Entity; 
create_listl->dcl jame — ent_j)trl->en _name; 



144 



create_j^istl->dcl_ent_ptr = ent_ptrl; 
create_listl->dcl_sub_ptr = NULL; 
createjistl->dcl^ext = NULL; 
create_list2 = kms_ptr->dki_create.dci_create; 
if (create^ist2 == NULL) 

{ 

kms_ptr->dki_create.dci_create = create^istl; 
create_list2 = NULL; 

} 

else 

{ 

while (create^ist2->dcl^ext != NULL) 
create^ist2 = create^ist2->dcl^ext; 
create^ist2->dcl_next = create^istl; 
createj_ist2 = NULL; 

} 

ini = TRUE; 

} 

else 

{ 

ent_ptrl = ent_ptrl->en^ext_ent; 

} 

} 

temp^ptr = temp_ptr->il^ext; 

} 

temp_ptr = kms_ptr->dki_temp_ptr; 
while (temp_ptr != NULL) 

{ 

in2 = FALSE; 

gen_ptrl = db_j)tr->edn_subptr; 

while ((gen_ptrl != NULL) && (in2 == FALSE)) 

{ 

if (strcmp(temp_j)tr->il_name, gen_ptrl->gsn_name) == FALSE) 

{ 

create^istl = dap_create^ist _alloc(); must create 
createJ.istl->dclj[iode_type = GenSub; 
createJ.istl->dcljame = gen_ptrl->gsn jame; 
createj.istl->dcl_ent_ptr = NULL; 
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create_l^istl->dcl_sub_ptr = gen jtrl; 
create^istl->dcl_next = NULL; 
create_list2 = kms_ptr->dki _create.dci_create; 
if (create^ist2 == NULL) 

{ 

kms_ptr->dki_create.dci_create = create^istl; 
createj_ist2 = NULL; 

} 

else 

{ 

while (create^ist2->dcl_next != NULL) 
create^ist2 = create^ist2->dcl ^ext; 
create^ist2->dcl jext = create^istl; 
create^ist2 = NULL; 

} 

ptr = gen_ptrl; 
proc_create(ptr); 
in2 = TRUE; 

} 

else 

{ 

gen_ptrl = gen_ptrl->gsn^ext_£enptr; 

} 

} 

temp_ptr = temp_ptr->il_next; 

} 

/* the recursive procedure follows */ 
proc_create ( ptr) ; 

{ 

gen_ptr2 = ptr; 

if (gen_ptr2->gsn_entptr != NULL) 

{ 

overlapent_ptrl = gsn_entptr; 
ent_ptr2 = overlapent_ptrl->oen jame; 
while (overlapent_ptrl != NULL) 

{ 

create^istl = dap_create^ist _alloc(); must create 
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create Jistl->dcljode_type = Entity; 
create listl->dcl name = ent_ptr2->en jame; 
create _l^istl-> del _ent_ptr = ent_ptr2; 
create^istl->dcl^ub_ptr = NULL; 
create^istl->dcl jext = NULL; 
create^ist2 = kms_ptr->dki_create.dci_create; 
if (create J^ist2 == NULL) 

{ 

kms_ptr->dki_create.dci_create = create^istl; 
create_list2 = NULL; 

} 

else 

{ 

while (create J^ist2->dcljext != NULL) 
create^ist2 = create^ist2->dcl^ext; 
create^ist2->dcl^ext = create J_istl; 
createj_ist2 = NULL; 

} 

overlapent_ptrl = overlapent_ptrl->oen jext jame; 

} 

} 

if (gen_ptr2->gsn_subptr != NULL) 

{ 

overlapsub_ptrl = gsn_subptr; 
gen_ptrl = overlapsub_ptrl->osn^ame; 
while (overlapsub_ptrl != NULL) 

{ 

create^istl = dap_create_list _alloc(); must create 
create^istl->dcl jode_type = GenSub; 
create^istl->dcljiame = gen_ptrl->gsn^ame; 
create^istl->dcl_ent_ptr = NULL; 
create_listl->dcl_sub_ptr = gen_ptrl; 
createj_istl->dcl^ext = NULL; 
create_^ist2 = kms_ptr->dki_create.dci_create; 
if (create_list2 == NULL) 

{ 

kms_ptr->dki_create.dci_create = create^istl; 
create J_ist 2 = NULL; 
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} 

else 

{ 

while (create^ist2->dcl^ext != NULL) 
create^ist2 = create^ist2->dcl_next; 
create^ist2->dcl^ext = create^istl; 
create^ist2 = NULL; 

} 

proc_cre ate (overlapsub_ptrl- >osn^ext^ame) ; 
overlapsubjptrl = overlapsubjptrl->osn jiext^ame; 
} 

} 

/* end recursive procedure */ 

} 

named _aggregate SEMICOLON 

{ 

} 



allocator: NEW 

namel^ist /* rule modified to LL(l) from LR(l) */ 
named _aggregate 



include_statement: INCLUDE ada_expression 
INTO indexed_component 
SEMICOLON 



exclude_statement: EXCLUDE ada_expression 
FROM indexed_component 
SEMICOLON 



destroy ^statement: DESTROY 

ada_expression SEMICOLON 
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move_statement: MOVE ada_expression move_from SEMICOLON 
I MOVE ada_expression move_to SEMICOLON 
I MOVE ada_expression move^rom move_to SEMICOLON 

j 

move from: FROM namel list 



move_to: INTO namel_list 

I INTO namel_list named _aggregate 



procedure_call: procedure ^ame SEMICOLON 

I procedure^ame parameter_part SEMICOLON 



parameter jpart: LP ada_expression^ist RP 



procedure jame: PRINT 
I PRINT J.INE 
I CANCEL 

I HEADER J>RINTJ.INE 
I FORMAT 
I FORMATJLINE 
I HEADER JFORMATJ.INE 



compound_statement: if_statement 
I atomic_statement 
I loop_statement 



if_^tatement: ifjpart end SEMICOLON 

I if _part elsif_list end SEMICOLON 
I if_part else_part end^ SEMICOLON 
I if _part elsif_J^ist else_part end^ SEMICOLON 
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if^part: IF condition THEN sequence_of_statements 



elsif_list: elsif_part 

I elsif_[ist elsif_part 



elsifjpart: ELSIF condition THEN s(equence_of_statements 



else_part: ELSE sequence_of_statements 



. end END 
! END IF 



atomic_statement: begin _atomic sequence_of_statements 
end atomic SEMICOLON 



begin _atomic: ATOMIC 

I IDENTIFIER COLON ATOMIC 



end _atomic: END 

I END ATOMIC 
I END IDENTIFIER 
I END ATOMIC IDENTIFIER 



loop_statement: 

real Joop SEMICOLON 

1 IDENTIFIER COLON real Joop IDENTIFIER SEMICOLON 
1 IDENTIFIER COLON real Joop SEMICOLON 
1 real Joop IDENTIFIER 



realjoop: iteration_clause basic Joop end Joop 
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basicj^oop: seqence_of_statements 

I LOOP sequence_of^tatements 



end^oop: END 

I END LOOP 



iteration_clause: iteration_body 

I iteration__body order_by_clause 



iteration_body: for_clause loopjparameter IN domain 



for_clause: FOR 

I FOR EACH 



loopjparameter: IDENTIFIER 
order_by_clause: BY order_component^ist 



order_component_list: order_component 

I order_component^ist COMMA order_component 



order_component: indexed_component 

I sort_order indexed_component 



sort_order: ASCENDING 
I DESCENDING 



sequence_of^tatements: dml_statement 

I sequence_of_statements dml_statement 
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condition: ada_expression 



generalized_expression^ist: generalized_expression 

I generalized_expression_list COMMA 
generalized_expression 

» 

generalized_expression: ada_expression 
I ada_range 
) 

ada_expression Jist: ada_expression 

I ada_expression_l^ist COMMA ada_expression 
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